DEV: Jak na zamek na databazi?

[Karel Zak]

On Wed, Mar 26, 2003 at 03:42:30PM +0000, Miroslav Prymek wrote:
> Dobry den,
> jeste jeden dotaz ohledne programovani serveru.
> V serveru jede pro kazdeho pripojeneho klienta jeden thread (a BLOKUJICI 
> socket), pricemz klienti posilaji pozadavky na zapis/cteni databaze, 
> kterou spravuje server. (Databaze je trosku silne slovo, jde o klasicky 
> obousmerne zretezeny seznam objektu. Nepouzivam zadnou knihovnu - 
> objekty a vsechno,
> co s nimi souvisi jsem implementoval sam).
> 
> PROBLEM: Chtel bych, aby zaroven mohlo libovolne mnozstvi threadu cist
> z databaze. Jestlize chce nektery thread zapisovat, zakaze dalsi cteni,
> pocka az soucasne cteni dobehne a potom zacne psat.
> TEDY CELKEM KLASICKA SITUACE.

 Urcite najdete radu implementaci R/W zamku pro pthreads. Napriklad
 aplikacni server Mape (mape.jcu.cz:-) presne to co potrebujete
 pouziva. Pracuje to naprosto spolehlive. Pokud o to mate zajem tak
 jsem to dal na FTP:
 ftp://ftp2.zf.jcu.cz/users/zakkr/th/thrwlock.tar.gz

 Je to pomerne jednoduche, jsou tam dve urovne. Ta vyssi predpoklada
 pole zamku a na zamky se odvolavate najakym ID ta nizsi pak pracuje
 primo se strukturou zamku. Je to vzdy jeden mutex lock pouzivany na
 strukturu co popisuje pocet threadu ktere ctou nebo cekaji.
 Pochopitelne ty cekajici to pokud jiz mohou zacit cist/zapisovat
 probouzi.

 Pokud chcete co nejvetsi propustnost tak bych pouzival zamky na
 urovni objektu a jeden globalni zamek pro modifikaci toho seznamu. 
 Jeste vetsi propustnosti pak dosahnete pokud nebudete pouzivat
 jednoduchy seznam, ale vetvici se strom kde kazdy uzel ma zamek na
 sva data (objekt) a dalsi zamek na pripadne potomky. Takto je delana
 napriklad cache Mape.

> Myslite, ze by bylo lepsi pouzit server s jednim threadem a
> neblokujicimi sockety (odpoada potreba blokovani databaze)?
> (vykonnost na viceprocesorovem stroji

 Je jeste treti varianta kde pocet thredu <= poctu klientu. To 
 znamena jeden thread muze obsluhovat vice klientu a to tak ze
 existuje nejaky seznam pozadavku plneny podle toho so prichazi 
 po siti -- tento seznam je obsluhovan threadem ktery nic jineho
 nedela. Ostatni thready si z tohoto seznamu "berou praci" vzdy 
 kdyz nemaji co delat nebo pokud spi tak je hlavni thread co obsluhuje
 seznam po pridani pozadavku probouzi. Tato implementace umoznuje i
 plynule prechazet na model, ze thread se venuje jen a pouze jednomu
 klientu - proste klient posle threadu informaci "ted se jiz nekoukej
 do zadneho seznamu pozadavku a jen cti muj socket". Muzete tak vyresit
 potrebu chvilkove narocnosti klienta na odezvu serveru.
 
 To "pocet thredu <= poctu klientu" je velmi efektivni tam kde klient
 ma vetsi prodlevu mezi pozadavky na server -- typicky kdy klienta
 obsluhuje klikajici clovek. Pochopitelne je to trosku vice narocne na
 implementaci ale jde to.

> nehraje roli - takovy stroj nemam a asi nikdy mit nebudu:)
> Spis se me to zda neelegantni z toho duvodu, ze pozadavky,
> posilane serveru maji ruznou, ale PEVNE DANOU delku, takze by
> bylo vhodne je PRECIST JAKO JEDEN BLOK. Jestlize by tedy
> klient z nejakeho duvodu pozdrzel psani uprostred bloku,
> server by zustal stat, coz je nepripustne.

 Pokud mate v serveru uzke hrdlo ktere slehuje pozadavky klientu tak by 
 melo pouze a jen sledovat -- napriklad pomoci select(). Cist data by melo 
 neco co neblokuje ostatni casti serveru, tedy thread.

> P.S. Je tahle konference vubec urcena i pro temata ohledne programovani?
> Nerad bych nejak obtezoval :)

 Jasne, pojdme se radeji bavit o tom jaka distribuce je nejlepsi... jsem
 pro debian :-)
 
    Karel

-- 
 Karel Zak  <zakkr na zf.jcu.cz>
 http://home.zf.jcu.cz/~zakkr/