C socket API es seguro para subprocesos?

Question

Estoy usando las API de socket de Linux y Win32. En mi programa, varios subprocesos comparten un identificador de socket. En particular, varios subprocesos llaman al send con el identificador de socket compartido (es decir, el mismo puerto). En este caso, ¿tengo que poner un candado para la seguridad del hilo? No pude encontrar la respuesta. Puedo hacer una prueba, pero quiero escuchar sus experiencias.

EDIT: Sé que el envío de datos a través de socket no es operación atómica en absoluto. Definitivamente tenemos que usar un mutex para seguridad de hilo. Sin embargo, me preguntaba si la API del sistema podría tener su propio bloqueo interno. Si es así, podemos omitir poner nuestro propio candado.

Esta pregunta también puede aplicarse a la función fprintf. Me pregunto si las API del sistema tendrían sus propios bloqueos. En mi experiencia, llamar al fprintf desde varios subprocesos no mató mi programa aunque hubo carreras en un archivo o stdout (es decir, salidas inconsistentes o impredecibles, pero el programa no se bloqueó), lo que implicaba fprintf tenía un bloqueo para proteger su interno estructura de datos.

Answer 1

Enviar datos a través de un socket no es una transacción atómica: cualquier transacción no atómica requerirá un bloqueo/sincronización. Esto es independiente de la plataforma.

Answer 2

Los sockets no son parte de C++ Standard, por lo que depende de la implementación. Generalmente no son seguros para subprocesos ya que send no es una operación atómica. Consulte this discussion para obtener información adicional.

EDITAR: El sistema operativo podría tener o no tener un bloqueo interno para proteger las estructuras internas. Depende de la implementación. Entonces no deberías contar con eso.

Answer 3

No, la variable creada con accept no necesita ser mutex. Cualquier información utilizada por los hilos debería ser al menos semáforos.

sem_t* sem_data; 

Answer 4

Encuentro las llamadas al descriptor de archivos multiple socket close() extremadamente peligrosas en un entorno concurrente.

Por lo general, se ignoran varias llamadas, pero en el caso de que otro hilo abra otro descriptor de archivo, con frecuencia se obtiene el descriptor de archivo anterior y se inicia una pesadilla.