[OSy] Uvolneni prostredku vlakna pri thread_kill

[Martin Decky]

Hezky den,

> Pokud ale bude zrovna vlakno v nejake kriticke sekci zamcene
> nejakym synchronizacnim primitivem, mohlo by vynuceni odemknuti tohoto
> primitiva zanechat jadro v nekonzistentnim stavu.

Zadani presne nespecifikuje, zda thread_kill() zrusi vlakno okamzite a v 
libovolnem stavu, nebo s nejakym pripadnym zpozdenim a nekdy taky vubec ne.

Situace, kterou popisujete, je totiz skutecne netrivialni a ruzne realne 
systemy se s ni vyporadavaji ruzne, napr. v Linuxu i jinych Unixech muze 
byt vlakno v tzv. "uninterruptible sleep" stavu, kdy jej proste zabit 
nelze. Urcite by Vam mohlo pomoci neuvazovat o thread_kill jako o 
nedelitelne atomicke operaci, ale o dvou operacich: oznaceni vlakna k 
zabiti a pripadny uklid jeho prostredku.

Obecne lze rici, ze neexistuje nejlepsi nebo dokonale reseni, takze se 
nad ruznymi moznostmi zamyslete, vyberte takove, ktere je konzistentni s 
chovanim zbytku Vaseho systemu a sva rozhodnuti zdokumentujte.

> Ja ale tvrdim, ze tam,
> kde by neco takoveho hrozilo, jsou (nebo by mely byt) stejne vypnute
> interrupty a thread_kill tam toto vlakno nemuze prerusit

Asi uvazujete v tom smyslu, ze se obvykle vypinaji preruseni tam, kde se 
nejak manipuluje s interni strukturou mutexu. Takze thread_kill() 
skutecne "nerozbije" konzistenci mutexu jako takoveho.

Na druhou stranu, jiste neplati, ze by byly zakazany preruseni po celou 
dobu, kdy je nejake vlakno v kriticke sekci daneho mutexu (tj. ma 
zamceny dany mutex). Pokud by to platilo, tak by mutex neumoznoval 
zlepsit paralelismus systemu v pripade vlaken, ktera nemaji zajem o 
stejny mutex, a cely koncept pasivni syschronizace by byl tak trochu 
zbytecny.

Bohuzel i ta otazka, jak zabit vlakno, ktere zrovna drzi mutex (i kdyz 
jej aktualne zrovna nezamyka ani neodemyka), je dost slozita.


M.D.