Threads x procesy

martin.kula na deltaes.cz martin.kula na deltaes.cz
Čtvrtek Říjen 11 12:20:35 CEST 2001


On Thu, 11 Oct 2001, Karel Zak wrote:

> 
>  - u forku stabilita muze byt vetsi protoze pri chybe jednoho potomka 
>    nemusi nutne pojit cela aplikace.
Hmm to je dulezite...

>  - u threadu muzete usetrit pamet pokud vam zadani aplikace dovoluje
>    ji sdilet (narozdil od forku kde se muzete nanejvys spolehnout jen
>    na copy-on-write)

>  - u threadu se snadneji pracuje se sdilenou pameti nez v pripade fork
>    reseni kde budete muset pouzivat napr. IPC (nakonec to muze i
>    ovlivnit stabilitu:-)

Zde neni volby ;-( IPC (shm a sem) protoze data musi sdilet i dalsi
procesy delajici neco jineho.

> 
>  Pokud vam nejaka prodleva mezi pozadavkem klienta a jeho vyrizenim 
>  nevadi (coz je caste) tak mozna, ze reseni obsluhovat to jednim 
>  procesem nemusi byt nutne spatne. Tedy lepe reseni pomoci dvou 

To je prave vec kvuli ktere jsem zacal uvazovat o vice procesech (nebo
threads) protoze po vetsinu casu sice nebudou delat nic (relativne), ale
kdyz bude potreba tak je nutna co nejrychlejsi odezva pri soucasne
obsluze ostatnich a sekvencnim zpracovanim bude znacne nizsi maximalni
pocet obsluhovanych zarizeni ;-(((

>  procesu (threadu). Kdy jeden prijma pozadavky a dava do fronty a 
>  dalsi je s te fronty cte a vyrizuje. Pokud je zrejme ze u toho 
>  vyrizovani bude nejake cekani (napr. na disk nebo sit apod.) nebo 
>  mate SMP stroj tak tech threadu "vyrizovatelu" muze byt i vice. Pokud 
        ^^^
;-)))

>  jsou mezi pozadavky klienta nejake prodlevy tak si myslim, ze casto 
>  pouzivany model kdy pocet klientu = pocet threadu je zbytecnost. 
>  Protoze po dobu co klient nic od serveru nechce tak ten thread klidne
>  muze obslouzit neco jineho. Kazdy thread preci jen nejakou tu pamet sezere.

Ted me napadl model vice procesu (thredu) kdy kazdy bude sekvencne
obsluhovat urcity pocet zarizeni.

> 
> > - zatizeni CPU
> > - slozitost programovani
> 
>  Budete muset vyresit zamykani te sdilene pameti (a to u jakehokoliv
>  reseni), tam bych videl to uzke hrdlo, ktere snadno da napsat blbe
>  a ktere se treba projevi az u vetsiho poctu konkurujicich si klientu.

;-))))))))))))

Diky

Martin



Další informace o konferenci Linux