[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