[so] [Lab 8] Greseala cond_{signal, broadcast}

[Călin Cruceru]

Salut,

Se specifică în laboratorul 8[1], la secțiunile despre deblocarea
thread-urilor blocate la o variabilă condiție, următorul lucru:

"Firul de execuție apelant trebuie să dețină mutexul asociat
variabilei condiție în momentul apelului acestei funcții."

ceea ce este greșit, cum se poate vedea în paragraful 5 din descrierea
din man page[2].

Aș fi modificat eu în mod normal, însă e o afirmație destul de
puternică și m-am gândit că este o idee mai bună să transmit asta pe
listă.

Mi se pare important aspectul acesta pentru că în combinație cu faptul
că în Java și Python așa se face, crează impresia că așa *trebuie*.
Spre exemplu în implementarea din C++ a std::condition_variable, la
metodele notify_{one, all}[3] se specifică la Notes:

"The notifying thread does not need to hold the lock on the same mutex
as the one held by the waiting thread(s); in fact doing so is a
pessimization, since the notified thread would immediately block
again, waiting for the notifying thread to release the lock. However,
some implementations (in particular many implementations of pthreads)
recognize this situation and avoid this "hurry up and wait" scenario
by transferring the waiting thread from the condition variable's queue
directly to the queue of the mutex within the notify call, without
waking it up."

[1]: http://ocw.cs.pub.ro/courses/so/laboratoare/laborator-08
[2]: http://linux.die.net/man/3/pthread_cond_signal
[3]: http://en.cppreference.com/w/cpp/thread/condition_variable/notify_one

Toate bune,
Călin