[OSy] navratova hodnota vlakna a platnost vlakna

[Martin Decky]

Hezky den,

> 1/ Funkce void *thread_start(void *data) má návratovou hodnotu. Co s ní?
> Přišlo by mi docela rozumné ji nějak vracet pomocí funkce thread_join,
> ale v jejím zadání nic takového popsáno není. U thread_join je mimo jiné
> popsáno, co má vracet v případě, že selže, ale není tam, co má vracet v
> případě úspěchu. Mám to chápat tak, že EOK a návratovou hodnotu funkce
> thread_start zahodí?

Mate velmi spravny postreh, v pripade kernelovych API metod pro praci s 
vlakny se navratova hodnota vlakna skutecne zahazuje. Nenapadla nas 
totiz zadna situace, kdy by se ta navratova hodnota k necemu prakticky 
hodila. Pokud takovy use-case mate, tak Vam samozrejme nic nebrani 
vytvorit si nad ramec zadani rozsirenou variantu thread_join(), ktera 
navratovou hodnotu vraci.

Na druhou stranu, vsimnete si, ze v pripade user space API se s 
navratovou hodnotou vlakna pracuje (viz thread_join() a thread_exit() v 
3. zakladnim zadani), takze interne s ni musi pracovat i kernel.

> 2/ Máme umět rozpoznávat u proměnných typu thread_t, jestli se jedná o
> platné vlákno. Něco takového je možné pouze jedním způsobem - držet si
> někde datovou strukturu, ve které budou spravována všechna vlákna
> (respektive pokud má někdo jiný způsob, tak bych ho rád znal, ale z
> ukazatele ani struktury imho nelze poznat, zda je platná, pokud
> zavrhneme řešení pomocí různých magic hodnot přímo v datové struktuře,
> což mi ale nepřijde jako moc čisté řešení - nebo stačí to poznat s
> nějakou velmi vysokou pravděpodobností?).

Otazka se opet rozpada na variantu pro kernelove a uspace API.

V pripade kerneloveho API lze klidne implementovat jen velmi zakladni 
ochrany, ktere nefunguji 100% spolehlive, ale maji minimalni overhead -- 
od testovani, zda thread_t neni NULL, pres testovani spravneho rozsahu 
adresy po testovani magic hodnot uvnitr struktury.

Nedava totiz moc smysl chranit jednu cast kernelu proti chybam v jine 
casti kernelu. Kernel tvori jednu bezpecnostni domenu, bezi v jedinem 
adresovem prostoru a mel by byt zkratka cely spravne. Je-li cely 
spravne, neni potreba testovat spravnost dat predavanych interne mezi 
kernelovym API (jinak nez testy s konstantni datovou slozitosti).

V pripade user space API je situace pochopitelne jina. User space bezi 
na jine bezpecnostni urovni nez kernel a nemel by za zadnych okolnosti 
(at nahodile ci zamerne) ohrozit stabilitu kernelu. Zde je tedy uz 
bezpodminecne nutne zajistit, aby uspace nemohl nejak podvrhnout nebo 
poskodit identifikator vlakna ci data s nim spojena.

Pouziti datove struktury (nebo vice struktur), ktera bude obsahovat 
vsechna platna uspace vlakna (nebo mapovani nejakych handleru vlaken na 
kernelove struktury vlakna), je tedy v tomto pripade asi nezbytne. Neni 
to vsak az takova komplikace, protoze takovou strukturu stejne 
potrebujete k tomu, abyste poznali, zda dany uzivatelsky proces 
manipuluje vyhradne se svymi vlakny a ne s vlakny jineho procesu.

> Jsou nějaké požadavky na
> rychlost této struktury? Může být toto ověřování lineární vzhledem k
> počtu vláken v systému? Pochopitelně není problém to udělat rychleji,
> ale stojí to práci navíc :o(

Trivialni optimalizace: Nemusi to byt linearni vzhledem k poctu vlaken v 
systemu, ale linerarni jen vuci poctu vlaken aktualniho procesu :-)

Jinak ale definitivni odpoved na Vasi otazku necham nezodpovezenou. 
Zalezi totiz na tom, jak casto se bude ta struktura v praxi pouzivat. 
Pokud jen obcas, muze byt klidne linearni. Pokud se bude pouzivat casto, 
mela by byt efektivnejsi.

Smeruje-li Vase otazka na to, zda za linearni seznam vlaken (per proces) 
budeme strhavat body, tak ma odpoved je, ze velmi pravdepodobne ne.


M.D.