2016-04-20 12:01 GMT+03:00 Laura Vasilescu <[email protected]>: > 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 _______________________________________________ http://ocw.cs.pub.ro/courses/so/info/lista-discutii
