2011-03-03 20 views
5

Supongamos que alguna variable de condición "cond" está asociada con una variable mutex "mutex". Si un hilo está durmiendo en cond después de llamar al pthread_cond_wait(&cond,&mutex), y ha finalizado otro hilo que tiene mutex bloqueado, ¿importa si el hilo llama a pthread_cond_signal(&cond) antes o después de llamar al pthread_mutex_unlock(&mutex)? ¿Necesita siquiera desbloquear el mutex si llama al pthread_cond_signal(&cond), ya que el hilo de dormir adquirirá el mutex de todos modos?Señalización de una variable de condición (pthreads)

EDITAR: Según https://computing.llnl.gov/tutorials/pthreads/#ConVarOverview, "No poder desbloquear el mutex después de llamar a pthread_cond_signal() no permite que se complete una rutina pthread_cond_wait() correspondiente (se mantendrá bloqueado)." Supongo que entonces, se requiere desbloquear, y quizás solo después.

+0

+1 por responder a su propia pregunta. –

Respuesta

3

Siempre debe desbloquear el mutex después de llamar al pthread_cond_signal. Aquí hay algunas buenas preguntas/respuestas para leer:

Calling pthread_cond_signal without locking mutex

No vendrán a mí en este momento, pero estoy bastante seguro de que hay una buena razón (en términos de condiciones de carrera) que usted don' Quiero desbloquear el mutex antes de señalizar.

+0

Si después de señalar la variable de condición y desbloquear el mutex, el hilo llama inmediatamente a 'pthread_mutex_lock()' en ese mutex, ¿se garantiza que no se agotarán los hilos previamente despertados por 'pthread_cond_signal()'? – ManRow

+1

@ManRow: puede haber tal garantía en la opción Programación prioritaria, si se establecen las prioridades correctas. De lo contrario, definitivamente no. –

+2

La buena razón es evitar la inversión de prioridad: http://groups.google.com/group/comp.programming.threads/msg/a3721a2fc9b21c64?hl=ky enlazado desde http://stackoverflow.com/questions/4544234/calling- pthread-cond-signal-without-locking-mutex/4544494 # 4544494 – ninjalj

4

Si mantiene el mutex bloqueado, entonces el hilo que se está despertando no puede adquirir el mutex, por lo que se bloqueará en pthread_cond_wait esperando para volver a adquirir el mutex.

No necesita mantener el mutex bloqueado para llamar al pthread_cond_signal. De hecho, si la lógica de su aplicación puede funcionar con una señal cuando el mutex no está bloqueado, entonces esa es una mejor manera de hacerlo --- el sistema operativo puede programar el hilo de espera de inmediato, y no tiene que esperar la señalización hilo para desbloquear el mutex antes de continuar.

Sin embargo, en este escenario se debe tener cuidado para asegurarse de que el despertador no se pierda, y no tenga un problema con el subproceso "incorrecto" que se está despertando. Si usa un predicado directo, esto no debería ser un problema en la práctica.

Cuestiones relacionadas