Thread-safe funkce v glibc

[Lubos Lunak]

Michal Krause wrote:
> 
> On 12/20/99 22:17, Ing. Pavel PaJaSoft Janousek wrote:
> > > Jojo, rekl bych, ze multithreadove aplikace se oproti forkovani lepe
> > > pisou a hur ladi...
> >
> >       A nejen to, bohuzel pokud nastane nejaka neocekavana chyba (neosetrena
> > vyjimka) v jednom vlakne, jde do kytek cely system (mysleno aplikace),
> > coz pri forku znamena zahubu pouze jednoho potomka... - nekdy si rikam,
> > zda-li je opravdu ta rezie pri fork a pak nejakem IPC tak velika, ze
> > tato implementacni a odladovaci (tedy robustnost) narocnost se
> > vyplaci... - asi jak kde a jak na co, pokud je priorita jedine rychlost,
> > pak asi jina cesta neni...
> 

 Tohle ale taky zalezi od cloveka a programu. Thready se nemusi pouzit
jen na zrychleni veci, nekteri ( napr. ja :) ) trpi predstavou, ze
thready psani veci naopak zjednodusuji. Kdybych si ja mel vybrat mezi
fork() a thready, nemam obvykle co resit - kdyz vidim fork(), jdou na me
neprijemne pocity. To, ze u threadu je to jen jeden bezici program, dela
spoustu veci jednodussich ( pouziti fork() na treba manipulace s
obrazkem na pozadi musi byt docela maso - a nebo spousta zbytecne IPC )
- cim vice spolu casti potrebuji komunikovat, tim vice vyhod prinasi
thready.
 To, ze jeden thread posle cely process do kyticek obcas muze vadit,
jenze kdyz na sobe ty casti vice zavisi, nemusi se to prezit ani pri
pouziti fork().
 Jinak, pokud se pouzije kooperativni MT, tak vetsina tech argumentu
typu 'slozite' pada a ve vysledku to muze byt nejjednodussi a
nejbezpecnejsi zpusob napsani nekterych veci, a clovek na to nemusi byt
ani tezky machr. No ale ja jsem clovek zaujaty, tak ted treba blabolim
*grin*.

> No ja na tohle nejsem zadny specialista, ale pokud me pamet neklame, tak
> vysledky predchozich debat na toto tema byly nasledujic:
> 
> a) zakladani threadu je prakticky stejne narocne jako fork (protoze
> thread je v Linuxu vlastne proces a pri forkovani se pouziva metoda
> copy-on-write
> b) thready jsou vyrazne rychlejsi pri prepinani, protoze sdili stejnou
> pamet, navic odpada nutnost duplikovat stranky pri zapisu
> 
> Nekdo vice v problematice zbehly by to jiste popsal fundovaneji, ale
> podstatu to snad vystihuje: pokud se pise aplikace, ktera zaklada
> thread/process s kazdym (relativne rychle zpracovanym) pozadavkem, je (v
> Linuxu!) IMHO uplne fuk, co pouzijete, na rychlosti se to vyrazne
> neprojevi.
> Pokud kazdy thread/process pracuje hodne a dlouho, dava pouziti threadu
> lepsi performance.
> 
> Nevite nahodou nekdo, co presne vede Apache Foundation k proklamovanemu
> prechodu na vlakna v Apachi 2.0? Je to otazka rychlosti nebo maji i
> jine duvody? Pokud je to rychlost, z ceho vysli? Z obecnych predpokladu
> nebo i z nejakych testu? Docela rad bych nejake rozumne srovnani
> videl...

 Neco o tomhle jsem zahledl nekde na http://www.gnu.org/software/pth ,
jen uz nevim presne kde ( .ps soubor u Pth ? ), ale bylo tam psano, ze
pokusna verze Apache s thready jela znatelne rychleji ( 'great
performance boost', jestli me pamet neklame ). Mozna to bude tim, ze Pth
jako user-space kooperativni MT knihovna jede jeste rychleji nez
LinuxThreads ( nemeril jsem to, ale nevidim duvod, proc by to tak byt
nemohlo ).


 Jeste k te glibc : Ja bych ji veril, ze thready zvlada v pohode,
nakonec to myslim byla jedna z veci, na ktere se pri psani glibc2
myslelo. No a jestli se na to myslelo, tak krome veci, ktere potrebuji
_r variantu, by nemel byt problem to napsat, aby to slo bez problemu
pouzit. ( Overit si to tedy bohuzel ale nemuzu, zdrojaky glibc2 jsou
zatim jedina vec, v ktere se mi zaboha nedari najit veci, ktere hledam
).

> 
> S pozdravem
> --
> Michal Krause                                                      /\
> ICQ: 7665279            Informace (nejenom) ze sveta Linuxu     /\/  \
> email: mike na navrcholu.cz ______ http://www.root.cz/ ______ NAVRCHOLU.cz
> 
> Co napsat do signatury, aby to nikoho nepohorsilo? Snad jedine nejakou
> obecne znamou pravdu. Doufam, ze vsichni vite, ze tucnak je bylozrava ryba.

 Lubos Lunak
 l.lunak na email.cz http://dforce.sh.cvut.cz/~seli     ---KDE Now!---