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

[Călin Cruceru]

2016-04-20 12:01 GMT+03:00 Laura Vasilescu <laura.vasilescu at cs.pub.ro>:
> Afirmația că trebuie e una prea puternică. Nu trebuie. Dacă vrei să ai
> totuși predictibilitate în sensul de a nu pierde singals, atunci
> trebuie să faci asta. Altfel riști să ajungi să ai fire de execuție
> blocate (dead-lock).
>

Eu am înțeles din linkul pe care l-am pus mai devreme că "predictable
scheduling" se referă la altceva, iar un program corect (fără
posibilitatea de deadlock) cu signal fix înainte de unlock va fi
corect și cu signal fix după unlock.  Cred că ar specifica în man page
dacă ar fi pericol de deadlock, iar în specificația din C++ pe care o
citasem în e-mailul inițial nu cred că ar încuraja să faci asta.

Diferența e mult mai subtilă; cred că paragrafele următoare din
explicația din acel link o sumarizează bine:

"The problem (from the realtime side) with condition variables is that
if you can signal/broadcast without holding the mutex, and any thread
currently running can acquire an unlocked mutex and check a predicate
without reference to the condition variable, then you can have an
indirect priority inversion.

[...]

Now, in "high performance thread" terms, this whole concept is generally
bad design; if the threads were symmetric and priority was associated
with the work (that is, higher priority work was simply at the head of
the queue to be handled by whatever consumer gets to it next), it
wouldn't matter that "the wrong thread" had the work item. (There is no
"wrong thread", only "wrong queued work"; and that can easily be managed
at the application level.)"

Călin