Newsgroup: it.comp.lang.c++
Titolo: Programmazione orientata agli eventi.

Salve.
Ho il seguente problema.
Nel mio programma ho vari "oggetti" implementati proprio con delle
classi C++.
Volendo che ogni oggetto fosse dotato di vita propria (volendo che, in
pratica, ognuno si facesse i fatti suoi) ho fatto in modo che ciascuno
di questi oggetti allochi un thread dedicato a sè. Il thread segue lo
stato dell'oggetto e ne provoca l'evoluzione attraverso chiamate ad
alcuni suoi metodi.
Ciascun oggetto, poi, ha degli handler di eventi ai quali, chi vuole,
dall'esterno si può aggangiare per ricevere la notifica delle
transizioni di stato.
Il problema è che in tutto questo nessuno mi assicura che i thread (che
sollevano gli eventi) non si scontrino all'esterno degli oggetti a cui
appartengono.
E neanche vorrei seminare di Mutex tutto il codice.
Qualcuno ha qualche consiglio da darmi?
Grazie,
Marcello.

 Qualcuno ha qualche consiglio da darmi?
Se gia` non lo hai fatto, studia ed imita il modello di gestione
degli eventi in Win32, che e` ben sviluppato e mi pare assai
congruente al tuo (per la contemporanea presenza di thread
multipli, oggetti [window] ed eventi); nota che il modello di
threading ed eventi del COM e` invece difforme al tuo (perche`
un oggetto COM multithread ben studiato NON ha tipicamente
thread affinity, bensi` e` free-threaded in generale -- mentre
una _finestra_ *ha* thread-affinity, e in effetti apposite finestre
invisibili e relative code-di-eventi sono il meccanismo usato dal
Service Control Manager per il "match di impedenze" fra oggetti
COM che si trovano ad aver posto vincoli di thread/apartment;
similmente, non vi e` thread-affinity degli oggetti in Java, e in
quel caso neppure la possibilita` di esprimere direttamente
questo vincolo...).
Naturalmente, gli oggetti-messaggio ("passivi" == non thread-
affini...!) che si scambieranno i tuoi oggetti-attivi (thread-affini)
potranno essere assai piu` ricchi dei semplici "messaggi" di
Windows (che trasportano poche parole di dati), ma questo non
cambia le problematiche fondamentali di gestione della coda
di eventi di ciascun thread.  L'altra differenza fondamentale
(che ti apparenterebbe di piu` a COM o Java) e` il modello
broadcast/subscription della propagazione degli eventi (il
concetto di "chi e` interessato si registra" -- pattern Observer
o similari), il che implica una semantica diversa per il "post"
di un evento (e un discreto "?" relativamente alle spedizioni
_sincrone_ di eventi -- il "send" -- se pure vuoi supportarle),
ma, di nuovo, non cambia tanto le cose relativamente alla
_altra_ "estremita`" della coda, quella ove gli eventi vengono
ricevuti/accumulati/e prima o poi, si spera, gestiti.
Alex

 modo nella tua architettura.
In questo scenario, la coda dovrebbe essere acceduta tramite
l'impostazione di un mutex, vero?
E questo sarebbe l'unico mutex da allocare (nell'ambito dello scambio
dei messaggi), vero?
Grazie tante,
Marcello.

 dei messaggi), vero?
Se i messaggi si clonano (ogni ricettore riceve una sua copia
privata) o se si occupano loro (con qualsivoglia mezzo) di
garantire l'accessibilita` simultanea da molti thread-clienti
(ad esempio, basta che siano read-only dopo la creazione,
con l'eccezione dell'operazione di decrementa-reference-count
che puo` usare InterlockedDecrement o simili approcci a
seconda della piattaforma), allora se la coda (o grab-bag)
di ciascun thread-ricettore fa il suo lavoro, non dovrebbe in
questo ambito essere necessaria nessun'altra sincronizzazione
(in particulare, nessuna mutua-esclusione, sezione-critica, o
simili costrutti "pesantucci" -- non parliamo neppure di quelli
_davvero_ pesanti come i semafori, naturalmente).
Alex

Qualcuno ha qualche consiglio da darmi?
Su computer programming 65 c'e` un ottimo articolo in
cui C. Pescio analizza il problema e cerca di costruire
una soluzione sulla falsariga di quello che avviene in
Eiffel... Non riesce a raggiungere pienamente lo scopo,
ma vi si avvicina molto. Credo che potrebbe interessarti
ed aiutarti.
Paolo
--------------------------------------------------
  Paolo Marotta
  Computer Science, University of Pisa
  home:   
http://www.cli.di.unipi.it/~marotta
--------------------------------------------------