Wywołanie pthread_cond_signal bez blokowania muteksu

Czytałem gdzieś, że powinniśmy zablokować muteks przed wywołaniem pthread_cond_signal i odblokować muteks po wywołaniu go:

Funkcja pthread_cond_signal () służy do sygnalizowania (lub wybudzania) innego wątku, który oczekuje na zmienną warunku. Powinien zostać wywołany po zablokowaniu muteksu i musi odblokować muteks, aby procedura pthread_cond_wait () została zakończona.

Moje pytanie brzmi: czy nie jest w porządku wywoływanie metod pthread_cond_signal lub pthread_cond_broadcast bez blokowania muteksu?

Jeśli nie zablokujesz muteksu w ścieżce kodowej, która zmienia stan i sygnały, możesz utracić wybudzenia. Rozważ tę parę procesów:

Proces A:

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

Proces B (nieprawidłowy):

condition = TRUE;
pthread_cond_signal(&cond);

Następnie rozważ możliwość przeplotu instrukcji, gdzie conditionzaczyna się jako FALSE:

Process A                             Process B

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

                                      condition = TRUE;
                                      pthread_cond_signal(&cond);

pthread_cond_wait(&cond, &mutex);

conditionJest teraz TRUE, ale jest zablokowany Proces A czeka na zmiennej warunkowej - to brakowało sygnał wzbudzenia. Jeśli zmienimy Proces B, aby zablokować muteks:

Proces B (poprawny):

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

... wtedy powyższe nie może wystąpić; przebudzenie nigdy nie zostanie pominięte.

(Zauważ, że możesz faktycznie przenieść to pthread_cond_signal()samo po znaku pthread_mutex_unlock(), ale może to spowodować mniej optymalne planowanie wątków i koniecznie zablokowałeś muteks już w tej ścieżce kodu z powodu zmiany samego warunku).

Zgodnie z tą instrukcją:

Te pthread_cond_broadcast()lub pthread_cond_signal()funkcje mogą być wywołana przez wątek, czy obecnie jest właścicielem mutex że wątki rozmów pthread_cond_wait() lub pthread_cond_timedwait()nie powiązanych ze zmienną stan podczas ich czeka; jednak, jeśli wymagane jest przewidywalne zachowanie planowania, wówczas ten mutex powinien być zablokowany przez wywołanie wątku pthread_cond_broadcast()lub pthread_cond_signal().

Znaczenie instrukcji przewidywalnego zachowania harmonogramu zostało wyjaśnione przez Dave'a Butenhof (autor książki Programming with POSIX Threads ) na comp.programming.threads i jest dostępne tutaj .

caf, w przykładowym kodzie Proces B modyfikuje conditionbez blokowania mechanizmu mutex. Jeśli Proces B po prostu zablokował muteks podczas tej modyfikacji, a następnie nadal odblokował muteks przed wywołaniempthread_cond_signal , nie byłoby problemu - czy mam rację?

Intuicyjnie wierzę, że stanowisko kawiarni jest poprawne: dzwonienie pthread_cond_signalbez posiadania blokady mutex to zły pomysł. Ale przykład kawiarni nie jest w rzeczywistości dowodem na poparcie tego stanowiska; jest to po prostu dowód na poparcie znacznie słabszego (praktycznie oczywistego) stanowiska, że ​​złym pomysłem jest modyfikowanie wspólnego stanu chronionego muteksem, chyba że najpierw zablokujesz ten muteks.

Czy ktoś może podać przykładowy kod, w którym wywołanie, pthread_cond_signalpo którym następuje, pthread_mutex_unlockdaje poprawne zachowanie, ale wywołanie, pthread_mutex_unlockpo którym następuje, pthread_cond_signaldaje nieprawidłowe zachowanie?