[OSy] upresneni zadani: thread_sleep vs. thread_wakeup

Martin Decky decky at d3s.mff.cuni.cz
Fri Nov 4 11:23:36 CET 2011


Hezky den,

> Zda se mi, ze zadani umoznuje dva vyklady vztahu funkci na uspavani
> threadu - thread_sleep + thread_usleep a funkce na probouzeni threadu -
> thread_wakeup:
>
> a) funkce thread_sleep resp. thread_usleep jsou na stejne urovni jako
> thread_suspend a thread_wakeup; tedy, ze thread uspany pres
> thread_sleep(N) se probudi bud sam po N sekundach a zaroven ho lze
> probudit behem spani explicitne z jineho threadu zavolanim thread_wakeup.
>
> b) funkce thread_sleep(N) uspi thread na N sekund a behem nich nebude
> thread na volani thread_wakeup() reagovat (napr. vrati EINVAL).

Myslim, ze zapominate na to, ze u popisu thread_sleep() a 
thread_usleep() je uvedeno:

"Vlakno nesmi byt zablokovano na kratsi dobu nez bylo zadano [...]"

Pokud by tedy bylo mozne vlakno zablokovane pomoci thread_sleep() a 
thread_usleep() odblokovat externim volanim thread_wakeup() jeste pred 
vyprsenim timeoutu, tu vyse uvedenou podminku by nebylo mozne dodrzet.

Jedina spravna se mi tedy jevi interpretace (b).

> Ta moznost (a) se mi zda prirozenejsi, logictejsi a i jednodussi na
> naprogramovani.

S tim poslednim kriteriem bych mozna souhlasil, ale otazka prirozenosti 
a logiky mi rozhodne tak jednoznacna neprijde. Funkce thread_sleep() a 
thread_usleep() totiz slouzi k tomu, aby si vlakno samo ridilo cas 
uspani/probuzeni bez moznosti vnejsiho ovlivneni. Zadna parova funkce k 
tomu potreba neni.

Zatimco thread_suspend() a thread_wakeup() jsou zrejme parove metody 
urcene pro jednoduchou formu event-driven uspavani a probouzeni. Jejich 
pouziti je jine nez v predchozim pripade.


M.D.




More information about the NSWI004 mailing list