On Monday 10 February 2003 14:59, Florin Malita wrote: > daca am inteles eu bine, suna a problema clasica de > producer/consumer. si cel mai elegant se rezolva cu semafoare: > consumerul asteapta pe un semafor pana cand producerul ii > semnalizeaza, pe urma producerul asteapta pe alt semafor pana > consumerul ii semnalizeaza. Este problema clasica producer/consumer, dar sunt putin legat si de anumite restrictii. 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. 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).
-- Dorin "sp00ky" Lazar, programmer Registered Linux user #162515 -- Pentru dezabonare, trimiteti mail la [EMAIL PROTECTED] cu subiectul 'unsubscribe rlug'. REGULI, arhive si alte informatii: http://www.lug.ro/mlist/
