Newsgroup: it.comp.lang.c++
Titolo: [HELP] Thread e condivisione di funzioni

Da poco sto cominciando a programmare in C++ dopo aver fatto diverse
esperienze in Java. Alcuni concetti restano un poco oscuri.
Ho realizzato un server multithreading: un processo esegue le accept e
genera un thread per client che gestisce tutto il ciclo di vita della
connessione.
Per gestire il protocollo o scritto un oggetto Protocol (globale nel
processo) i cui metodi vengono invocati dai singoli thread.
Es.
se un thread vuole comunicare da socket seguendo il protocollo fara':
protocol->cfp(this->socket); // call for proposal
protocol->request(this->socket);
protocol->inform(this->socket);
L'oggetto protocol è passato dal thread server a tutti gli altri ed è
unico.
LA DOMANDA
E' un pattern sicuro rispetto ai thread switch?
L'accesso alle strutture dati di Protocol è protetto da mutex, ma il
mio dubbio è riferito alle variabili locali interne alle funzioni
dell'oggetto protocol. Questo è dovuto alla mia ignoranza sulla
gestione della memoria nei thread.
Se un thread si blocca nel bel mezzo di un inform() mentre avviene un
thread switch e il thread seguente esegue ancora un'inform() il codice
delle due funzioni sono copiati in due spazi differenti?
Dimenticavo il SO è Linux o Win32 utilizzando la libreria <pthread.h>
e il compilatore è gcc 2.9.x
Scusate l'ignoranza se la domanda è banale.

 delle due funzioni sono copiati in due spazi differenti?
Se non ricordo male, ogni thread ha un suo stack,quindi
le variabili locali sono indipendenti (ip invece puo´ puntare alla stessa
istruzione da != thread). Se comunque un metodo di protocol usa variabili
globali, le devi ´blindate´
in qualche modo (semafori o mutex) come pare gia´ fai.
Pattern sicuri x proteggere i dati dei  thread non esistono. Sei tu che devi
capire esattamente chi e come puo´ modificare una vrb ed eventualmente
preservare il valore se ti serve dopo.
Se vuoi un ottimo libro, prova a dare un´occhiata al Butenhof (ISBN:
0201633922)
ciao


 Scusate l'ignoranza se la domanda e` banale.
Va la`, le domande non sono mai banali :)
Cmq, ricordati di inserire un #define _REENTRANT nei file del progetto
*prima* di ogni altro #include.
ciao
Kronos
-- 
Home: 
http://kronoz.cjb.net
Not an editor command: Wq

*prima* di ogni altro #include.
 why?

 why?
 - Macro: _REENTRANT
 - Macro: _THREAD_SAFE
     If you define one of these macros, reentrant versions of several
     functions get declared.  Some of the functions are specified in
     POSIX.1c but many others are only available on a few other systems
     or are unique to GNU libc.  The problem is the delay in the
     standardization of the thread safe C library interface.
     Unlike on some other systems, no special version of the C library
     must be used for linking.  There is only one version but while
     compiling this it must have been specified to compile as thread
     safe.
In pratica  vengono usate delle  versioni "speciali" di  alcune funzioni
che   possono  aver   bisogno  di   controllo  aggiuntivi. Ad   esempio,
normalmente getc/putc sono implementati  come macro, mentre se definisci
_REENTANT diventano  vere e proprie  funzioni, visto che  sono necessari
dei lock sullo stream.
Quindi, o inserisci #define _REENTRANT, oppure ti ricordi di compilare
con -D_REENTRANT
ciao
Kronos
-- 
Home: 
http://kronoz.cjb.net
Al termine di un pranzo di nozze mi hanno dato un
amaro alle erbe cosi' schifoso che perfino sull'etichetta
c'era un frate che vomitava.