2012-06-30 14 views
5

escribir llamadas a funciones desde múltiples hilos en el mismo socketes seguro usar la función de escritura en GNU C usando múltiples hilos

¿es seguro? ¿Queríamos agregar una sincronización entre ellos? ¿Causará problemas lado a otro como Aplicación conseguir retrasó escritura/lectura de la capa de red de capa de aplicación

Estamos utilizando GNU C++ bibliotecas GCC 4 en Linux RedHat Enviornment

Este es un proceso del lado del servidor, donde Sólo hay 1 zócalo de conectividad entre el servidor Cliente servidor & & cliente son el 2 diffent Máquinas de datos se envía del servidor al cliente cliente al servidor

Problema 1-cuando el servidor envían datos al cliente (múltiples Hilos Escribir dat a del lado del cliente a través del mismo zócalo único) Pero los datos escritos de algunos de los hilos no se han ido al lado del cliente, ni siquiera han ido a la red Capa del mismo equipo (Tcpdump no tiene esos datos)

Problema 2-cuando el cliente envía datos a Server Data Send By Client se muestra en el TCPdump del servidor no recibido para la aplicación del servidor que está leyendo desde el socket desde un solo hilo usando "leer" & "seleccionar" funciones en un bucle

No pudimos identificar el patrón de ocurrencia de estos problemas. Pensamos que esto sucedió cuando tantos hilos múltiples están escribiendo en el mismo zócalo. No estamos sincronizados con la función de escritura esperando que el sistema operativo maneje la sincronización

+0

Es "seguro" en el sentido de que su programa está bien formado, pero los resultados que ve en su socket pueden no ser los que espera. –

+0

@KerrekSB: es un comentario extraño. Cualquier programa inseguro de subprocesos podría llamarse "seguro" en ese sentido, ¿no? –

+0

@NedBatchelder: seguramente no. Por ejemplo, una función que depende de un búfer estático para su mantenimiento de estado interno es simplemente * no * seguro para subprocesos, y un programa que lo llama varias veces al mismo tiempo está mal definido. Por el contrario, un programa que llama 'write' al mismo tiempo no está mal definido automáticamente. –

Respuesta

0

No es seguro utilizar write() desde varios subprocesos. No hay garantía de que la salida no se mezcle conjuntamente. Una escritura podría poner la mitad de sus bytes en el socket, y luego otra escritura podría comenzar a poner bytes. Si necesita asegurarse de que cada escritura se escriba contiguamente (y es difícil imaginar que no necesite esa garantía), entonces necesita un candado o algún otro método de sincronización.

+0

gracias Ned. ¿Causará los problemas anteriores? – samira

+0

@samira: sin duda podría causar los problemas que ha descrito, pero es imposible determinar si la causa es la sincronización. –

+1

Al acceder a la función puede usar mutex para que solo un hilo acceda a la función a la vez ... – shofee

1

write() es una llamada al sistema, no una función de biblioteca, y las llamadas al sistema generalmente se garantizan como atómicas.

+3

Verdadero, y no es cierto. Se garantiza que la llamada del sistema sea atómica (y "segura" en el sentido de que no bloqueará ni dañará sus datos) pero no hay garantía de que los datos sometidos simultáneamente (atómicamente) por dos hilos sean _transferred_ atómicamente: [lectura interesante] (http://www.almaden.ibm.com/cs/people/marksmith/sendmsg.html). También tenga en cuenta que 'write' y' send' están técnicamente autorizados a escribir menos de lo que pide, en cuyo caso debe continuar con una segunda operación de escritura, perdiendo toda atomicidad de todos modos. – Damon

0

No se especificará cuál de las write llamada completa primero. Un cambio de contexto podría detener cualquiera de las dos escrituras en la primera instrucción. Esto puede conducir a un orden arbitrario. No hay nada write o el kernel puede hacer eso. Es un problema fundamental.

Sus datos se escribirán en un orden no especificado que probablemente no sea aceptable para usted.

Cuestiones relacionadas