[OSy] Dealokovanie detached vlakna po normalnom skonceni

[Michal Klempa]

Zdravim,
predem dakujem za trpezlivost. Pisem nizsie.

On Thu, 04 Nov 2010 12:21:32 +0100
Petr Tuma <petr.tuma at d3s.mff.cuni.cz> wrote:
> 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 ... ?

Hmm, no to je zase pridanie nejakej haluze na koniec schedule().
Uz tam mame na zaciatku spracovanie timerov:-)
Ked nevymyslime lepsie, spravime nejaku taku prasarnu.

> 
> > 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).

Cize ak thread ID neexistuje, dam mu EINVAL.

Ak thread ID existuje a nahodou je to uz ine vlakno (znovu pouzity
thread ID dajme tomu po preteceni 32 bitoveho thread ID a predsa sa
nezasekne pocitac koli tomu preteceniu), nemam sancu vediet, ze je to
uz raz predtym neplatne thread ID a teraz znvoa platne. Je to chyba
toho, kto zavolal kill a ja mu nedam EINVAL a on si killne ine vlakno,
ako zamyslal. Jo?

> 
> Petr Tuma
> 
> 
> _______________________________________________
> OSy mailing list
> OSy at d3s.mff.cuni.cz
> https://d3s.mff.cuni.cz/mailman/listinfo/osy