Chiamando pthread_cond_signal senza mutex bloccaggio

Question

Ho letto da qualche parte che si debba bloccare il mutex prima di chiamare pthread_cond_signal e sbloccare il mutext dopo definendolo:

La routine pthread_cond_signal () è usato per segnalare (o svegliare) un altro filo che aspetta sulla variabile di condizione. Dovrebbe essere chiamato dopo mutex è bloccato, e deve mutex sbloccare in modo che pthread_cond_wait () di routine per completa.

La mia domanda è:? Non è vero OK per chiamata pthread_cond_signal o pthread_cond_broadcast metodi senza bloccare il mutex

Answer 1

Se non si blocca il mutex in percorsi di codice che cambia la condizione e segnali, si può perdere wakeups. Considerate questa coppia di processi:

Processo A:

pthread_mutex_lock(&mutex);
while (condition == FALSE)
    pthread_cond_wait(&cond, &mutex);
pthread_mutex_unlock(&mutex);

Processo B (errato):

condition = TRUE;
pthread_cond_signal(&cond);

quindi prendere in considerazione questo possibile suddivisione delle istruzioni, dove condition inizia come FALSE:

Process A                             Process B

pthread_mutex_lock(&mutex);
while (condition == FALSE)

                                      condition = TRUE;
                                      pthread_cond_signal(&cond);

pthread_cond_wait(&cond, &mutex);

Il condition è ora TRUE, ma Processo A è attesa bloccato sulla variabile di condizione - è perso il segnale di sveglia. Se alter Processo B per bloccare il mutex:

Processo B (corretto):

pthread_mutex_lock(&mutex);
condition = TRUE;
pthread_cond_signal(&cond);
pthread_mutex_unlock(&mutex);

... quindi quanto sopra può non avviene; la sveglia non sarà mai perso.

(Si noti che è possono effettivamente spostare il pthread_cond_signal() sé dopo la pthread_mutex_unlock(), ma questo può risultare in meno pianificazione ottimale di thread, e hai necessariamente bloccato il mutex già in questo percorso di codice a causa di cambiando la stessa condizione).

Answer 2

Secondo questo manuale:

Il pthread_cond_broadcast() o funzioni pthread_cond_signal() può essere chiamato da un thread se o non attualmente possiede il mutex che filetti di chiamata pthread_cond_wait() o pthread_cond_timedwait() hanno associato alla variabile condizione durante le loro attese; tuttavia, se comportamento scheduling prevedibile è richiesto, quindi che mutex sarà bloccato dal chiamante filo pthread_cond_broadcast() o pthread_cond_signal().

Il significato del il comportamento di pianificazione prevedibile dichiarazione è stata spiegata da Dave Butenhof (autore di Programmazione con POSIX Thread ) su comp.programming.threads ed è disponibile qui .

Answer 3

caf, nel codice di esempio, modifica il processo B condition senza bloccare il mutex prima. Se Processo B semplicemente bloccato il mutex durante quella modifica, e poi ancora sbloccato il mutex prima di chiamare pthread_cond_signal, non ci sarebbe nessun problema --- ho ragione di questo?

Credo intuitivamente che caf di posizione è corretta: chiamando pthread_cond_signal senza possedere il blocco mutex è una cattiva idea. Ma caf di Esempio non è in realtà prove a sostegno di questa posizione; è semplicemente la prova a sostegno della posizione molto più debole (praticamente ovvia) che è una cattiva idea di modificare lo stato condiviso protetto da un mutex a meno che non si è bloccato che mutex prima.

Qualcuno può fornire alcuni esempi di codice in cui chiamare pthread_cond_signal seguito da rendimenti pthread_mutex_unlock comportamento corretto, ma chiamando pthread_mutex_unlock seguito da rendimenti pthread_cond_signal comportamento scorretto?