thread

[Jan Kasprzak]

	Dobry vecer,

	Dovolim si trochu delsi pojednani k nasledujicimu dotazu:

Filip Zaludek napsal:
: 
:  Muze mi prosim nekdo, nekdo kdo s konecnou
: platnosti pochopil rozdil mezi threadem a procesem,
: jaky je mezi nimi rozdil?
: 
:  Nechci odpovedi typu:
: "Thread je odlehceni proces".
                     Y

	V tradicnim pojeti threadu (pojem vznikl v operacnim systemu
VMS, pokud se nepletu) jde skutecne o odlehcenou variantu procesu,
to jest (jak uz zde bylo receno) thready mezi sebou sdili adresovy
prostor a nektere dalsi systemove udaje (PID, otevrene soubory
a podobne).

	Thready je mozne implementovat ciste v uzivatelskem prostoru
(to jest udelame nejakou ridici funkci kolem sluzby jadra select(2)
a pomoci longjmp(3) prepiname "kontexty"). Toto ma nektere vyhody
(vse je v uzivatelskem prostoru, v nekterych pripadech je to rychlejsi
(ne vzdy -- viz dale)) a nektere nevyhody (pokud se jeden thread
zablokuje napriklad uvnitr jadra cekanim na nejakou operaci,
stoji i ostatni thready protoze z hlediska systemu jde jen
o jeden proces). User-space thready podle normy POSIX.1c
implementuje napriklad knihovna pthreads. [Ne uplne podle normy,
protoze POSIX specifikuje, ze volani exec*(2) ma nahradit
pouze jeden thread. A to v uzivatelskem prostoru nelze].

	Krome toho je mozne thready implementovat v jadre.
Vyzaduje to jistou podporu v jadre, muze to byt pomalejsi,
zabira to vice prostredku systemu a podobne. Na druhe strane
thready s podporou jadra je mozne pouzit napriklad k implementaci
asynchronniho I/O (POSIX.4) nebo k rozlozeni zateze na vice procesoru
na SMP strojich. Linux poskytuje jistou podporu threadu s pomoci
jadra -- viz knihovna linuxthreads, ktera se vyskytuje nekde
na ftp.inria.fr.

	V linuxu jsou procesy i thready zvlastni pripady obecnejsiho
mechanismu, kteremu Linus rika Context of execution (COE). Tato
myslenka (spolu se sluzbou jadra clone(2), kolem ktere je postavena)
pochazi ze systemu Plan9. Specialnim pripadem COE je napriklad
proces, vzniknuvsi volanim fork(2), ktery nema s rodicem spolecne
zadne systemove prostredky. Anebo thread, ktery ma s rodicem
spolecne vse -- otevrene soubory, adresovy prostor, nekdy i
zasobnik, a v budoucnu bude v Linuxu implementovano i sdileni PID.
Anebo si muze uzivatel vybrat cokoli mezi tim; v <linux/sched.h> se pise:

#define CLONE_VM      0x00000100 /* set if VM shared between processes */
#define CLONE_FS      0x00000200 /* set if fs info shared between processes */
#define CLONE_FILES   0x00000400 /* set if open files shared between processes */
#define CLONE_SIGHAND 0x00000800 /* set if signal handlers shared */
#define CLONE_PID     0x00001000 /* set if pid shared */

	Program se muze treba rozhodnout, aby COE-potomek nesdilel
pracovni a korenovy adresar, ale jinak mel vsechno spolecne
s rodicovskym COE (pomoci CLONE_FS) a podobne.

	A jeste k implementaci a k rychlosti:
Synchronizaci threadu (semafory, mutexy) lze udelat temer uplne
v uzivatelskem prostoru pomoci instrukci typu test-and-set tak,
ze se v implicitnim pripade (kdy proces neni na mutexu blokovan)
obejdete bez prepnuti kontextu do jadra. Prepinani kontextu mezi
thready je jen o malo pomalejsi nez u user-space threadu (oproti
prepnuti kontextu mezi procesy se nemusi vylevat TLB) a navic Linuxovy
scheduler preferuje prepnuti kontextu do COE se stejnou pameti
(to jest do jineho threadu teze ulohy). User-space thready pri skoku
do jineho threadu usetri jedno prepnuti kontextu do jadra a zpet.
Na druhou stranu clone-based thready maji jednodussi uschovani kontextu
predesleho threadu pri prepnuti -- je to delano primo hardwarovymi
prostredky procesoru.

	Tak to je vse k Linuxu a threadum.

-Yenya

-- 
Jan "Yenya" Kasprzak <kas na muni.cz>            http://www.fi.muni.cz/~kas/
[[       This message was sent from my home machine running Linux.     ]]
[[ Visit the Czech Linux Homepage at http://www.fi.muni.cz/~kas/linux/ ]]
Only wimps use tape backup:  _real_ men just upload their important stuff
on ftp, and let the rest of the world mirror it ;)       --Linus Torvalds