Ladeni multithreadove aplikace

[Mikulas Patocka]

>> No a co kdyz velky proces, ktery bude mit namapovano treba 512M
>> virtualni pameti bude chtit pustit maly podproces?
>
>To teoretizujete, nebo mate nejaky maly priklad? Holt si pak
>musite drzet nejaky socket k "malemu spoustedlu", a pozadat to
>"male spoustedlo", at to udela za vas.
>
>Ale mam pocit, ze jste si ten priklad vyspekuloval.

WWW server pousti cgi skripty. FTP server pousti ls, gunzip a jine
programky.

>> Pri threadech vsak k zadnemu kopirovani page tablu ani k cow
>> nedochazi. Proto budou thready porad rychlejsi, nez dobre udelane
>> forkovani.
>
>Otazka je, zda natolik vyrazne.
>
>> >Proste tak, ze se fork()ujici aplikace napsala dobre. Zapisy jsou jen
>> >do par presne lokalizovanych mist, a ne rozesete po cele pameti.
>>
>> Pokud to nemelo stranky, tak jediny mozny zpusob implementace forku
>> byl zkopirovat fyzicky celou pamet procesu - a to je hrozne pomale.
>
>Nepotrebuji thready nejakou podporu od procesoru?

Ne. Leda by procesor mel mit atomicke instrukce, coz vetsna ma. Bez
nich to sice taky jde, ale muselo by se kvuli zamkum chodit do kernelu.

>A mimochodem, jak udelate (aspon trochu efektivne) per-thread
>storage, pokud neumi procesor strankovat?

Delat per-thread storage pomoci strankovani neni dobra idea, protoze
cely smysl threadu (sdileni page table) se tim znici. Nedavno to nekdo
na l-k pozadoval a byl odmitnut.

Identifikator threadu se muze dostat z ukazatele zasobniku (pokud se
zasobniky alokuji na znamych pozicich).
Nebo se taky da pouzit i386 segmentace (FUJ).

Mikulas