Salut Flavius, 2016-04-20 0:19 GMT+03:00 Flavius Anton <[email protected]>: > Salut Călin, > > În mare parte ai dreptate, așa scrie în manual, însă cred că următoarea > afirmație din acel paragraf din manual[2] reprezintă cheia: “however, > if predictable scheduling behavior is required, then that mutex shall > be locked by the thread calling pthread_cond_broadcast() or > pthread_cond_signal().”. > > Un răspuns foarte bun l-am găsit aici[4]. Nu am reușit să găsesc ceva > mai “oficial” care să-l susțină însă. > > [4] http://stackoverflow.com/a/4567919/1488669 >
Răspunsul de după cel către care ai dat tu link conține un link către explicația[5] a ceea ce înseamnă "predictable scheduling behavior" dată de unul dintre cei care au lucrat la standardul POSIX.1c. Ideea din câte înțeleg e că existând un timp între unlock și signal, se poate ajunge la "indirect priority inversion", cum o numește el; adică deși ai un thread de prioritate mare care așteaptă în coada variabilei condiție, dacă fix în acel timeslice vine un thread de prioritate mică și ia mutex-ul, atunci acesta va executa zona critică și nu thread-ul de prioritate mare, care se va trezi doar să aștepte din nou. [5]: https://groups.google.com/forum/?ro=ky#!msg/comp.programming.threads/wEUgPq541v8/ZByyyS8acqMJ Călin _______________________________________________ http://ocw.cs.pub.ro/courses/so/info/lista-discutii
