On Mon, 2003-02-10 at 15:30, Dorin Lazar wrote: > Producator-ul (la randul lui un consumer) trebuie sa citeasca datele > dintr-un socket. Bit-rate-ul este foarte mare, de aceea trebuie sa fie > cat mai rapid. Regula spune ca nu am voie sa am apeluri blocante acolo.
Apeluri blocante la trimiterea datelor catre consumator presupun, nu vad de ce nu ar putea face blocking read de pe socket. > Consumer-ul are un buffer pe care il umple si are prelucrari in rafala > (adica periodic, in functie de date, poate incepe o "rafala" de lucru > intensiv cu CPU-ul). Sistemul pe care lucrez e single-processor, deci > nu ma prea pot baza pe faptul ca producatorul va lucra in paralel. > Perioadele la care porneste "rafalele" sunt foarte mici si ele - si de > aceea am nevoie de un schimb rapid intre producator si consumator. > Problema este ca scheduler-ul Linux are o granularitate de 10 > milisecunde (pe i386). Eu am nevoie de ceva mult mai rapid. Am incercat > un sistem cu semnalare prin conditii POSIX - buffer-ul de comunicatie > insa e prea repede extenuat - problema este ca nu pot sa ii pun fraie > producatorului pentru ca va pierde date. Nu pot sa pun nici un buffer > urias (deja buffer-ul are 1M) pentru ca vor fi mai multe instante de > astfel de fire care preiau date din socketi - si deja am cerinte prea > mari la memorie. Totul ar fi ok daca cumva as putea sa il fortez pe > consumator sa isi faca treaba. Sugestia (prin semafor) ajunge la firul > celalalt prea lent (si prea des prea tarziu). OK, sper ca am inteles in mare. Q: chiar ai nevoie de 2 threaduri? de ce nu procesezi datele in acelasi thread care le citeste? Doar pe SMP ai avea de castigat din multi-threading... Gandeste-te un pic: folosesti 2 threaduri pt a nu pierde date la intrare, insa de fapt nu faci decat sa muti problema la bufferul dintre threaduri si sa introduci in plus latente datorate granularitatii scheduler-ului. Input-ul e buffer-at oricum de catre socket (poti eventual mari bufferul) asa ca e putin probabil ca vei pierde date. (priveste problema astfel: socket buffer == buffer-ul tau dintre threaduri => threadul producator dispare). Asa ca eu iti recomand sa incerci in felul urmator: maresti buffer-ul socket-ului si procesezi datele pe masura ce le citesti (rafale, whatever). Situatia ramane cam aceeasi (oricum producatorul trebuia sa astepte pana consumatorul facea loc in buffer, nu?) dar scapi de IPC si latente scheduler. -- Florin Malita web: http://www.malinux.net public key: http://www.malinux.net/data/fmalita.gpg -- Attached file included as plaintext by Listar -- -- File: signature.asc -- Desc: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQA+R8q59npXhj/Ohf8RAvclAKCY5zRMU7jrjMxlAbD7AuzOawdxuACggDTq mv55n4DSijg4UJSKPt3dznI= =RlLq -----END PGP SIGNATURE----- -- Pentru dezabonare, trimiteti mail la [EMAIL PROTECTED] cu subiectul 'unsubscribe rlug'. REGULI, arhive si alte informatii: http://www.lug.ro/mlist/
