Bună Călin, 2016-04-20 9:55 GMT+03:00 Călin Cruceru <[email protected]>: > 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
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). Laura _______________________________________________ http://ocw.cs.pub.ro/courses/so/info/lista-discutii
