[OSy] Uvolneni prostredku vlakna pri thread_kill
Martin Decky
decky at d3s.mff.cuni.cz
Thu Nov 4 15:16:02 CET 2010
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.
More information about the NSWI004
mailing list