[OSy] Datovy typ thread_t

[Andrej Krutak]

Dobry den zelam aj ja :-)


Tiez ma toto este zaujima... Su teda spravne (z vasho pohladu) oba nasledujuce 
pristupy:
1) vracat uzivatelovi len nejake ID
2) vracat (ako thread_t) pointer na nejake miesto pamati, kde si jadro ale 
alokovalo nejaku strukturu o vlakne

?

* Prvy pripad vyzaduje nejaku 'konverznu' tabulku (ID->structure pointer, 
alebo sa napr. priamo alokuje pole struktur), ale vracia vcelku pekne cisla 
ID threadov (napr. pre debug ucely). Nevyhoda je nevyuzite miesto v pamati (v 
blbom pripade dost velke mnozstvo nevyuzitej pamati (aj pri recyklacii thread 
ID)).

* Druha moznost je alokovat a vracat pointre na alokovane struktury. Tu 
dostane 'uzivatel' nie prilis pekne ID (alla 0x800a34e5), a ma k tomu moznost 
(resp. je to jednoduchsie ako v prvom pripade) lahsie strukturu 'poskodit'. 
Vyhoda je optimalne vyuzitie pamati...

Mozno je aj viac moznosti, my sme riesili len na tieto... A aj ked uz mame 
implementovanu prvu 'verziu' - to druhe sa mi teraz zda trosku vhodnejsie (co 
sa tyka vnutornosti jadra, asi nemusime pocitat so 'zakernym 
programatorom'...). 

Preto sa chcem opytat, co odporucate pouzit radsej (lepsie skrytie 
implementacie vs. lepsie vyuzitie pamati) - aby sme zbytocne neprisli o body 
hned na zaciatku :-)


Mozno este jedna vec - malo by byt thread_t "cislo" nejakym sposobom 
dlhodobejsie unikatne alebo je v OK, ak po thread_kill() dalsiemu vytvorenemu 
vlaknu pridelime to iste cislo ako mal ten posledne zabity? Viem si 
predstavit, ze by v takomto pripade mohli vzniknut zaujimave problemy napr. 
ked by vlakna cez thread_join(id) cakali na nieco ine ako mysleli :-)

Ak by to cislo malo byt nejake skoro-unikatne, prve dve moznosti riesenia, co 
je to to thread_t by asi odpadli - a nastupili by zrejme nejake hashovacie 
tabulky (ako tak rozmyslam pocas pisania) :-/


Snad sa nepytam prilis vela - ked tak staci napisat ze "it's up on you" :-) 
Ale radsej sa to opytat, ci nie je nieco z toho uplne zle, teraz ako za 
tyzden prepisovat polku zdrojakov...


Zdravi,
Andrej Krutak


On Friday 19 October 2007 13:04:07 Petr Tuma wrote:
> Dobry den,
>
> tato formulace pouze upozornuje, ze uzivatel se nema spolehat na zadne
> vlastnosti typu thread_t, pouze vi, ze instanci tohoto typu muze funkce
> thread_create nejak inicializovat a dalsi funkce pouzit ...
>
> Petr Tuma
>
> david.hauzar.os at seznam.cz wrote:
> > Dobry den,
> >
> > co prosim presne znamena, ze datovy typ thread_t je pro uzivatele
> > rozhrani "nepruhledny"? Znamena to napriklad, ze thread_t je jenom
> > identifikace vlakna a uzivalel vnejsiho rozhrani se pres nej nedostane do
> > ridici datove struktury vlakna?
> >
> > Tedy definice thread_t:
> >
> > typedef struct thread_struct {
> > ...
> > } *thread_t;
> >
> > nebude to prave orechove...? :)
> >
> > Diky,
> > David
> >