¿Por qué es necesario bloquear un mutex antes de llamar al pthread_cond_wait?pthread_cond_wait y requisito de exclusión mutua
Además, ¿es necesario llevar un candado (en el mismo mutex) antes de llamar al pthread_cond_signal?
gracias por su ayuda.
¿Por qué es necesario bloquear un mutex antes de llamar a pthread_cond_wait?
Porque de lo contrario hay una condición de carrera inevitable.
Un mutex protege el estado compartido. Una variable de condición está asociada con algún predicado ("condición") en el estado. La idea básica es que desea:
1) Comprobar el predicado
2) si el predicado es falsa, ir a dormir hasta que se convierte en verdadera
En un sistema concurrente, que siempre es posible para algunos subprocesos para que el predicado sea verdadero entre (1) y (2). Para evitar esta carrera, debe mantener un mutex antes (1) y debe liberarlo atómicamente a medida que realiza (2).
Por ejemplo, para una cola, el predicado podría ser "la cola no está vacía". Pero entre el momento en que comprueba si la cola no está vacía y la hora en que se va a dormir, algún otro subproceso podría agregar algo a la cola.
Por lo tanto, debe mantener el mutex al tiempo que verifica el predicado y en el momento en que llama a pthread_cond_wait.
Además, ¿es necesario realizar un bloqueo (en el mismo mutex) antes de llamar a pthread_cond_signal?
Que yo sepa, no hay un problema fundamental con esto; solo introduce ineficiencias potenciales.
Aquí otra vez, cualquier estado compartido que esté modificando (y haciendo así que el predicado sea verdadero) tiene que estar protegido por un mutex. De modo que cada vez que desee para señalizar la condición, debe mantener el mutex de todos modos.
Si suelta el mutex antes de señalar la condición, es posible que el predicado se vuelva falso entre ellos debido a la acción de algún otro hilo. Esta raza no causa fallas porque cualquier hilo que espere la condición debe verificar el predicado de todos modos antes de continuar ... Pero ¿por qué ponerlo en problemas?
En pocas palabras: Simplemente siga las instrucciones y ni siquiera tiene que pensar en estas preguntas. :-)
+1 para una respuesta detallada. :-) Creo que requerir el bloqueo de la señalización es garantizar la consistencia de la memoria, ya que bloquear un mutex implica una barrera de memoria. Sin él, otros hilos pueden no ser capaces de observar el cambio. (Sin embargo, supongo que es posible tener la barrera de memoria _al_ señalización. Pero, probablemente sea más sencillo requerir un bloqueo.) –
@Chris: 'POST requiere pthread_cond _ *()' para sincronizar la memoria: http: // pubs. opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_11 – ninjalj
@ninjalj: Ah, muy bien. ¡Gracias! :-) –
Las variables de condición son para sincronizar en una condición que está esperando cambiar. Bloqueo asegura que:
Un sistema de condición que no usa mutexes sería mucho más frágil.
El punto de las variables de condición es permitir que los subprocesos sean notificados de los cambios en las estructuras de datos protegidas por un mutex, p. Ej. es posible que desee recibir una notificación cuando una cola ya no esté vacía, por lo que liberará atómicamente el mutex y esperará la variable de condición, y cuando un nuevo elemento esté en cola, se despierta y toma el mutex para procesar el nuevo elemento.
A diferencia de los monitores de Java, pthread_cond_{signal,broadcast}() no necesita mantener el mutex. Se pierde la señalización de una variable de condición cuando no hay hebras esperando esa variable de condición, pero eso no debería marcar una gran diferencia, ya que la señal también podría perderse si el productor comienza a funcionar antes que el consumidor.
Vea también: http://stackoverflow.com/questions/4544234/calling-pthread-cond-signal-without-locking-mutex – ninjalj