Newsgroup: it.comp.os.linux.development
Titolo: Problema di sincronizzazione

Salve a tutti.
Sono un nuovo scrittore, ma vecchio lurkatore del NG... e spero di non 
andare OT :-)
Ho un problema di sincronizzazione nell'implementazione di un piccolo 
progetto sotto linux.
In poche parole, ho tre processi, che accedono ad una variabile condivisa 
(tenuta su della memoria condivisa) protetta da un mutex.
Processo 1 (padre): deve essere l'ultimo ad accedere alla variabile 
condivisa, per leggere il suo valore e processarla per vari scopi.
Processi 2 e 3 (figli): operano sulla variabile condivisa in maniera 
concorrente (non importa quale sia l'ordine reciproco con il quale vi 
accedono)
Ora: non posso mandare tutti e tre i processi in maniera concorrente sul 
mutex, rischio che il processo 1 non sia l'ultimo ad accedere alla 
variabile.
Ho pensato allora di eseguire una sleep() sul processo 1 prima che il 2 ed 
il 3 inizino a lavorare. Ma in questo caso non so chi, tra il processo 2 e 
3, debba risvegliare il proc. 1, visto che non so quale sarà l'ultimo ad 
accedere alla variabile.
Non posso fare una wait o una waitpid sul proc. 1, perchè dopo questa 
operazione i proc. 2 e 3 non terminano.
Una soluzione a cui ho pensato è creare un semaforo intero inizializzato a 2 
su cui mandare in wait il processo 1. Finito di lavorare, i processi 2 e 3 
decrementano il semaforo, ed 0 il padre viene risvegliato. Ma non la trovo 
una soluzione molto elegante.
Quale può essere il modo più elegante ed efficiente per risolvere questo 
problema?
Credo di aver esposto il problema in maniera non molto chiara, ma spero 
comunque che qualcuno possa aiutarmi (o consigliarmi un NG dove sono meno 
OT, in caso :p)
Grazie in anticipo per aiuto ed attenzione
Fabrizio

 progetto sotto linux.
...
Potresti fare un secondo mutex inizializzato a 0 sul quale il padre va in
wait dopo aver forkato i figli. Poi l'ultimo dei figli ad elaborare lo
alza ad 1 ed il padre puo' riprendere.
-- 
  Giuseppe "Cowo" Corbelli \/\ My software: 
http://cowo.yoda2000.net
    **ANTI-SPAM** -- **Substitute IHATESPAM with cowo to reply by mail** 
-<! When I was young I used to pray for a bike. Then I realized that God 
	 doesn't work that way. So I stole a bike and prayed for forgiveness. !>-

 alza ad 1 ed il padre puo' riprendere.
Purtroppo il problema è proprio questo :-/ : non so quale sia l'ultimo dei 
figli ad uscire.
L'accesso alla risorsa è concorrente, bloccata dal mutex. Per cui non so 
quale sia il primo ad entrare, di conseguenza non so chi sia il secondo ad 
uscire.
Per il momento ho "risolto" con un semaforo contatore inizializzato a -1, in 
modo che servono due post (uno per ogni figlio che esce) sul semaforo per 
poter sbloccare il padre.
Non ho ancora fatto un debug decente, per cui non so neanche se funziona, 
comunque sia non mi sembra una soluzione elegantissima.
Fabrizio

 accedono)
Bhe... io qui ci vedo solo una variabile condizionale su cui il padre è
in attesa e che viene segnalata quando entrambi i figli hanno effettuato
l'operazione.
Volendo potresti fare in modo che quando entrambi i figli hanno operato,
nel momento di riaccedere nella sezione critica, se essa è occupata dal
padre,  vanno in attesa su un'altra variabile condizionale (segnalata
ovviamente dal padre)
Sono varie idee, tutto dipende da cosa e come i processi devono operare.
PS. se usi c++ ti consiglio vivamente di utilizzare le commoncpp che ti
forniscono di mutex, thread e quanto altro, naturalmente usando i phthread
-- 
| /
| \Byte - Andrea Briganti - kbyte(aaattt)
despammed.com
CSLug member: 
http://cslug.linux.it
 - JID: 
kb...@jabber.linux.it
***Ogni ideologia o movimento non è immune dagli idioti

 comunque sia non mi sembra una soluzione elegantissima.
Perche'? E' veloce e funziona.
NP: Bob Catley - Carpe Diem
-- 
  Giuseppe "Cowo" Corbelli \/\ My software: 
http://cowo.yoda2000.net
    **ANTI-SPAM** -- **Substitute IHATESPAM with cowo to reply by mail** 
-<! Living on Earth may be expensive, but it includes an annual free trip
		around the Sun. !>-

 Perche'? E' veloce e funziona.
Anzitutto grazie per le opinioni ed i suggerimenti.
Bhe... ad essere onesti non lo so perchè non la vedo elegantissima... una 
sensazione :-)
In effetti però funziona.
Riguardo la soluzione di Kbyte... uhmmm, se non ho capito male (ed è 
possibile che lo abbia fatto) si tratta di un'attesa attiva su una 
variabile... ed anche qui non mi sembra elegantissima come soluzione (ok, 
sono un pignolone :p).
Ad ogni modo grazie per l'aiuto
Fab

 una soluzione molto elegante.
Che c'e' di poco elegante nell'usare un semaforo?
Se non ti piace un semaforo inizializzato a 3 puoi fare una seconda 
variabile mutex inizializzata a 0, i processi 2 e 3 la incrementano e il 
processo 1 accede alla variabile sotto mutex solo se la seconda 
variabile vale 2.
Bye,
  Gabry

 una soluzione molto elegante.
ed invece e' elegante. All'universita' te lo insegnano come
il problema della "barriera". Ti rimando ad un mio post[1] sulla 
ML dell'universita', io li' avevo avuto un problema a causa del 
flag SEM_UNDO, comqunque il codice che trovi fa esattamente quello 
che proponi tu.
[1]
https://srv.inroma.roma.it/pipermail/sistemioperativi/2003-November/000269.html
ciao
-- 
mattia
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG