Ladeni multithreadove aplikace

Michal Krause michal na krause.cz
Pátek Leden 21 13:58:55 CET 2000


On 21/01/2000, Stanislav Meduna wrote:

> : Jde o implementaci toho jednouceloveho HTTP serveru, o kterem jsme se
> : tady bavili asi pred mesicem, kdyz jsme probirali moznosti paralelizace
> : Navrcholu, takze princip aplikace je nasledujici: hlavni thread ceka na
> : pozadavky (accept()) a pak otevereny socket predava pracovnim threadum,
> : ktere ctou, parsuji a vyrizuji requesty.
> 
> Otazka c. 1 - ma multithreading zmysel? Nestacila by jedna
> slucka a prislusny stavovy automat?

Ano, ma smysl. Cilem je mimo jine zaridit, aby se pozadavek vyresil co
nejrychleji, klient se odpojil a pak se teprve data zpracovavala a
ulozila do databaze (pokud jsi nesledoval ten starsi thread o
paralelizaci, tak jenom upresnuju, ze nejde o obycejny HTTP server, pro
ktery prace konci odeslanim odpovedi, ale o potvoru, ktera zprcovava
data a uklada je do MySQL databaze).

> MT ma v tomto pripade zmysel ked:
> - ide o proces, ktory tvori vacsinu CPU zataze daneho stroja

Priblizne 20% permanentne

> - alebo trva vybavovanie niektorych poziadaviek dlho a ine
>   zatial musia byt obsluhovane

I tohle plati, je dulezite, aby pozadavky byly reseny navenek co
nejrychleji, aby nebrzdili nacitani stranek, kde je umisten odkaz na NV.
 
> Ak je spracovanie kratke, s trochou smoly sa moze stat,
> ze je odovzdanie prace inemu threadu drahsie ako
> spracovanie v single-threaded aplikacii :-(

To by snad nastat nemelo.
 
> : Problem je, ze pracovni thread (zatim to testuju s jednim) mi ze zatim 
> : neznamych duvodu duvodu kolabuje. Jelikoz ani s pomoci ladicich vypisu
> : jsem nebyl schopen najit pricinu,
> 
> Ladiace vypisy su v MT aplikacii na houby - bud je vypis
> taky zmatok, ze sa v nom neda vyznat, alebo ovplyvnia
> beh threadov tak, ze sa aplikacia sprava uplne inak
> ako bez nich. Vitaj v svete multithreadingu :-)

Potesujici :)
 
> : Takze jsem se chtel zeptat zkusenejsich, jestli lze z vyse uvedeneho
> : zjistit mozna pricina, pripadne jak postupovat, abych chybu nasel.
> 
> 99.9% zahadnych problemov v MT aplikaciach je zabudnuta
> alebo chybna synchronizacia medzi threadmi. A na to funguje
> zobrat si ceruzku a papier, nakreslit funkcie spolu s datami,
> ktore spracovavaju, a kde sa tie data prekryvaju, hladat 
> nejaku moznost, ako do nich mozu vliezt dva thready
> naraz.

Jenze ja to zatim ladim s jednim pracovnim threadem a jednim pomocnym,
ktery pouze jednou za dvacet minut zreviduje jeden zasobnik, pricemz
mezi hlavnim (main()), pracovnim a pomocnym se sdili pouze dve datove
struktury, obe chranene pro zapis mutexem. Ale je fakt, ze clovek nikdy
nemuze dat ruku do ohne za to, ze tam urcite chyba neni. Jeste jednou si
to projdu, kdyz se mi povedlo vytvorit deadlock v ramci jednoho threadu,
neverim uz nicemu :) 

> Mimochodom, urcite su vsetky subory kompilovane s -D_REENTRANT? :-)

Mely by byt, ale radeji to take jeste proverim...

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. 


Další informace o konferenci Linux