Newsgroup: it.comp.os.linux.development
Titolo: [?] Programmazione multiprocesso con fork(): come eseguire un azione atomica?

Salve a tutti, sto creando un piccolo programma multiprocesso, ora io
utilizzo l'istruzione fork() per duplicare il processo ... volevo
chiedere:
- Le variabili dichiarate prima della fork() sono condivise dai processi ?
se no come si fa a condividerle ?
- Come si fa ad eseguire un blocco di codice atomico (cioè solo un processo
alla volta lo deve eseguire) ?
Sarei grato a chiunque potesse postare un pò di codice in C per spiegarmi
meglio
perchè dal manuale non ci ho capito molto ...
GRAZIE


Per questo tipo di cose forse e' meglio usare i thread. Se ne e' parlato
meno di un mese fa su questo newsgroup. Prova a fare una ricarca con google.
Alessandro

 perchè dal manuale non ci ho capito molto ...
Ci sono stati vari thread a riguardo, su questo newsgroup.
http://groups.google.com
 is your friend.
Bye,
 Emmanuele.
-- 
Emmanuele Bassi (Zefram)           [ 
http://www.radiance.d2g.com/~zefram
 ]
GnuPG Key fingerprint = 4DD0 C90D 4070 F071 5738  08BD 8ECC DB8F A432 0FF4

Per queste operzioni, usare fork() non basta. Devi usare i thread.
Sě puň, mica deve :-)
Per esempio, codice atomico si fa con locking su file, e per la
condivisione delle variabili un mmap. 
-- 
Per rispondermi, ricordati di togliere il 
nome del poeta e il trattino.

 condivisione delle variabili un mmap.
Grazie per l'aiuto!
Mi potresti fare un semplice esempio di utilizzo di queste due tecniche?
oppure un link dove posso trovare info a riguardo ?
Quello che devo implementare è un Proxy che gestisca le richieste dei
Processi Client, prenda i dati dai processi server e li rispedisca ai
client.
Pensi che usare la fork() sia la soluzione migliore ? (mi sa che SONO
OBBLIGATO a usare solo quella ...)
CIAO e Grazie Mille!

Pensi che usare la fork() sia la soluzione migliore ?
Apache funziona cosě, e a te non servono prestazioni maggiori, vero?


 Per esempio, codice atomico si fa con locking su file,
Questa e' una tecnica di sincronizzazione piuttosto scarsina.
Va bene quando c'e' di mezzo un operatore umano (es. un utente
che avvia due istanze di X-Window), ma con dei processi, per
di piu' correlati, direi di no.
Supponiamo di usare questa tecnica, ovviamente il primo che
apre in maniera esclusiva il file esegue il codice. Il prossimo
aspetta. Come aspetta, lo mettiamo in sleep? Per quanto? Che succede
se il processo si sveglia e trova ancora il lock? Lo rimandiamo
a nanna?
Supponiamo che sia cosi'. Puo' accadere che un apltro processo
che si sveglia subito dopo il primo trovi il file libero ed
esegua la sua brava sezione critica. Supponiamo che la sezione
critica non sia banale, ma preveda l'accesso esclusivo ad una
risorsa di I/O. Ovviamente il processo riottiene il controllo
dopo intervalli di tempo non deterministici: il primo processo
che ha tentato di accedere al file si sveglia e lo trova ancora
occupato: si rimette a nanna. Il processo che originariamente
deteneva il file intanto si sveglia e acquisisce il lock sul
file e cosi' via.
Situazione improbabile? Puo' darsi. Una delle leggende
informatiche di mia conoscenza cita che alla sostituzione
di una macchina si e' trovato un processo in coda di stampa
da anni: era sempre stato scavalcato da processi a priorita'
superiore.
Una tecnica migliore e' quella di usare semafori. Il processo
che tenta di accedere ad una sezione critica e la trova occupata
viene sospeso e risvegliato al termine dell'esecuzione del processo
occupante. Tutti i processi che tentano di eseguire la sezione
mentre questa e' occupata vengono sospesi in una coda e risvegliati
in sequenza.
Spero sia chiaro :-)
Qualche esempio sull'uso dei semafori lo trovi
http://www.google.com/search?as_q=unix+semaphore+use+example&num=10&hl=it&ie=UTF8&oe=UTF8&btnG=Cerca+con+Google&as_epq=&as_oq=&as_eq=&lr=&as_ft=i&as_filetype=&as_qdr=all&as_occt=any&as_dt=i&as_sitesearch=
Un link che mi e' sembrato molto interessante e'
http://www.cs.cf.ac.uk/Dave/C/CE.html
HTH
C:\>iao Angelo
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG


No, se utilizzato correttamente, va' bene anche "in automatico".
Le race conditions sono sempre in agguato, ma il programmatore
accorto le evita (con equilibrismi a volte un po' estemporanei,
lo ammetto :-).
Alessandro.

 lo ammetto :-).
Io sono dell'avviso che il programmatore accorto gli equilibrismi
estemporanei li evita (se possibile) ;-)



Certo.
Solo che non mi andava che si dicesse che non funziona ;-).
Alessandro.

Questa e' una tecnica di sincronizzazione piuttosto scarsina.
Fino ad Apache 1.3.x si fa proprio cosě, e nessuno ha avuto molto da
obiettare sulle prestazioni. 


 obiettare sulle prestazioni.
I motivi per cui ritengo questa tecnica di sincronizzazione scarsina,
li ho esposti. Spero con sufficiente chiarezza, se non li ritieni
validi spiegami il motivo: il fatto che Apache abbia usato questa
tecnica fino alla versione 1.3.x, mi sembra debole come argomentazione.
Che poi sia una tecnica che e' stata usata, viene usata e verra' usata
non ci piove.
Inoltre, ul fatto che nessuno abbia avuto motivi di lamentela sulle
prestazioni di Apache, permettimi di dissentire. Per quale motivo
credi che il team di sviluppo abbia introdotto i thread? Solo perche'
e' piu' figo complicarsi la vita?


credi che il team di sviluppo abbia introdotto i thread? 
Perchè con Windows ci si guadagna in prestazioni.
Quanto alle prestazioni di Apache, non sono ottime in senso assoluto
(come tu invece lasci intendere di pensare, ma magari ho capito male
io), visto che usa un approccio process driven e non event driven, ma
siccome nessuno ha scritto ancora un web server event driven sotto GPL,
la minestra è quella. 


 io), ...
Non mi sembra di aver mai detto (ne pansato) una cosa del genere,
sono perfettamente convinto che IIS dal punto di vista strettamente
prestazionale sia superiore ad Apache, come una F1 e' piu' veloce
di una BMW.
Ma sono anche convinto che tutta questa differza sulle strade normali
non si noti, anzi alla prima buca un po' piu' profonda (leggi code red,
Nimda & Co.) la F1 si ferma la BMW, magari rallenta, ma continua a
camminare.


 condivisione delle variabili un mmap. 
Beh, al posto del file locking, possiamo pure andare giu` pesanti di
semafori, che hanno anche il vantaggio di non caricare il filesystem,
nel caso di molti processi.


non si noti, 
Appunto, quindi un locking via file basta ed avanza.


 Appunto, quindi un locking via file basta ed avanza.
Va bene, scusa se ho avuto l'ardire di attaccare un mio post
al tuo.
C:\>iao Angelo.



Claudio, nah, non sei obbligato ad utilizzare solo quella; ad esempio, senza
fork()are il processo per lasciarne uno in ascolto e l'altro connesso al client,
puoi utilizzare una select()...
"man" is your friend, e trovi tantissima roba su
http://www.CS.UniBO.It/~ghini/didattica/lab_prog_rete/lpr_index.html
Adieu,
-- 
Lestat de Lioncourt                            |             Ciro Mattia Gonano
  JabberID: 
les...@jabber.students.cs.unibo.it
 |       Undergraduate Student in
  ICQ#: 52631406                               |            Computer Science at
  URL: 
http://www.CS.UniBO.It/~gonano
          |          University of Bologna
         <powered by Linux Slackware 8.1-beta2 on Kernel 2.4.18-xfs>