[OSy] Dealokovanie detached vlakna po normalnom skonceni

[Petr Tuma]

Dobry den,

> :) OK, tak to asi zvladnem nejakym garbage collectorom.

No a to je prave to slozite reseni :-) co treba pridat do thread
struktury boolean flag "destroy me on context switch" a modifikovat
context switch tak, aby v pripade nastaveni tohoto flagu behem prepinani
kontextu udelal ten free ... ?

> Este pridam otazku, ze ci mozu dva thready volat rozne metody
> thread_xxx na jednu thread_t.
>
> Tym by sa mi mohlo stat, ze jeden ide thread killnut - je na
> zaciatku funkcie thread_kill, este nezakazal interrupty. schedule.
> druhe vbehne do metody thread_join povedzme, je na zaciatku,
> nestihol zakazat interrupty. schedule.
>
> prvy killne a uvolni vlakno.schedule.
>
> druhy zakaze interrupty a saha na dealokovanu pamat lebo mu vlakno
> zmizlo pod rukami. A to sa mu stalo, lebo mu zradny kolega poslal
> svoj thread_t handle (co je u nas pointer na strukturu thread).
>
> V zadani nie je vyslovene napisane (alebo som zas noob?) ze ci to je
> dovolene/zakazane takto tie vlakna pouzivat. Ak je to dovolene, musim
> si navzdy pamatat nejake handles vlaken s tym, ze toto je platne a
> pointer je tam, toto je neplatne, daj volajucemu facku.

Obecne je v takovemhle pripade dobre kouknout na pozadavky v zadani. 
Zadani vyslovene rika, ze funkce pro praci s vlakny maji byt schopne 
poznat neplatne identifikatory vlaken. Vedle toho je asi jasne, ze 
kernel nema zadne veci, kterych je potencialne neomezeny pocet, alokovat 
nekonecne dlouho. Z techto dvou veci dohromady vyplyva, ze 
identifikatory vlaken mohou byt zneplatneny a casem prideleny jinemu 
vlaknu, a z toho dal vyplyva ze veci jako paralelni kombinace 
thread_kill s jinym volanim budou mit vzdy potencialni race (protoze 
kdyz neumite zajistit, aby se thread_kill udelal jako posledni operace 
na danem thread ID, tak soucasne neumite zajistit, ze jine funkce volane 
na stejnem thread ID omylem nebudou manipulovat s jinym vlaknem).

Tedy shrnul bych to asi tak: volani thread_kill a thread_join (a 
thread_detach, svym zpusobem) maji jako jednu z dulezitych vlastnosti 
to, ze soucasne zneplatnuji dane thread ID. Pokud nekdo vola API tak, ze 
je mozne toto neplatne thread ID jeste znovu pouzit, tak je to jasne 
jeho chyba (ale kernel by to nemelo zborit).

Petr Tuma