Newsgroup: it.comp.os.linux.development
Titolo: Threads, pipes and select

Salve a tutti,
ho due processi P (produttore) e C (consumatore); i due sono collegati
tramite pipe, con C che ha una select() sulla pipe, in modo da
aspettare che arrivi qualcosa da P, e finche' non arriva dorme sulla
select senza rubare cicli processore.
La stessa cosa funziona anche coi thread?  Se avessi invece due
pthread P e C, potrei collegarli con una pipe e avere una select() in
C e funzionerebbe nello stesso modo?
Thx.


Per la serie "thread + read/write = ?" - sì, con i pthread funziona.

 Per la serie "thread + read/write = ?" - sì, con i pthread funziona.
Piu` che altro: "conviene" ??? Essendo thread, andrei sempre di 
mutex/condition... Ma magari e` complesso modificare l'applicazione...
my 2 Ec
-- 
                          | Hai presente quando chiudi gli occhi e 
\|/ ____ \|/   \ ||_|     | vorresti tanto che si avverasse un 
"@'/ ,. \`@"    \|| |     | tuo desiderio?
/_| \__/ |_\ Vax Headroom | Ecco, Dio è quello che ti ignora
   \__U_/                 |

 mutex/condition... Ma magari e` complesso modificare l'applicazione...
E' che mi sembra controintuitivo; se il consumatore deve aspettare che
il produttore faccia qualcosa, pipe+select esprime esattamente questo:
il consumatore si blocca alla select, e quando il produttore scrive
qualcosa nella pipe il consumatore si sblocca e lo consuma.
Con un lock come faccio? Avrei una coda condivisa e un lock; il
produttore deve tenere il lock se non ha niente da scrivere, in modo
che il consumatore si blocchi cercando di acquisire il lock? E lo
rilascia dopo aver scritto qualcosa nella coda, e poi deve continuare
a leggere la dimensione della coda finche' non vede che il consumatore
l'ha svuotata, e a quel punto riacquisire il lock (o qualcosa di
equivalente)? Mi sembra molto macchinoso, o mi sono perso qualcosa?
Thx,
Pleg

Interfacciandosi alla mia unità neurale, Pleg disse:

start:
   Il consumatore acquisisce il lock sulla coda[1], se vuota si mette in 
attesa su una condition[2] (equivalente ad una select) che, atomicamente, 
rilascia anche il lock. Quando il produttore ha qualcosa di pronto, 
acquisisce il lock, scrive nella coda, segnala la condition e rilascia il 
lock. A questo punto il consumatore (o i consumatori, ne puoi avere quanti 
ne vuoi sulla stessa coda) esce dalla condition e, sempre atomicamente, 
riacquisisce il lock, legge quanto c'è da leggere, rilascia il lock ed usa 
quanto letto. Quando ha finito goto start; :D
Share & Enjoy...
Vh
[1] - La coda può essere implementata come preferisci: un array, uno stack, 
una linked list ecc ecc ecc... (tempo addietro avevo implementato, in c++, 
un oggetto "pipe" usando una std::deque + boost::mutex)...
[2] - man pthread_mutex_lock, pthread_cond_wait, pthread_cond_broadcast, 
pthread_cond_signal, ma anche google...
[2bis] - Se preferisci qualcosa di OO c'è anche la libreria (c++) boost-
thread che, a sua volta, su linux, si appoggia ai pthread...
-- 
                          |
\|/ ____ \|/   \ ||_|     |   Siamo in missione 
"@'/ ,. \`@"    \|| |     |   per conto di Dio !
/_| \__/ |_\ Vax Headroom |
   \__U_/                 |         Jake Blues

[cut]
Capito, non ho mai usato le condition, ci do' un'occhiata, thx!
Pleg

Vax, posso rubarti la firma ?
E' geniale!  :D
-- 
rIO.sK

 E' geniale!  :D
Non e` mia:
http://it.wikiquote.org/wiki/The_Island
eppoi e` random :D
-- 
                          | "Ubuntu" e' un'antica parola
\|/ ____ \|/   \ ||_|     | africana che significa:
"@'/ ,. \`@"    \|| |     | "Non sono riuscito ad installare
/_| \__/ |_\ Vax Headroom |  Debian"
   \__U_/                 |


Io ruBBo lo stesso quella del post precedente  :D
-- 
rIO.sK