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

[Laura Vasilescu]

Bună Călin,

2016-04-20 9:55 GMT+03:00 Călin Cruceru <so at cursuri.cs.pub.ro>:
> Salut Flavius,
>
> 2016-04-20 0:19 GMT+03:00 Flavius Anton <f.v.anton at gmail.com>:
>> 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