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

[Călin Cruceru]

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

Călin