Newsgroup: it.comp.lang.delphi
Titolo: Multithread, Async ed architettura del programma

Ciao Raga.
Ho un "piccolo" problemino architetturale :-)
Dunque, il programma si compone di diversi thread che contengono al
loro interno un componente ApdComPort.
Ho anche un thread che fa da manager per i thread suddetti.
Come dovrei realizzare la comunicazione tra i thread Async ed il
manager? Io stavo pensando a due approcci diversi:
1) Uso di eventi nel thread Async( OnCommand, ecc ) messi in
hook nel thread manager
2) Uso di un hack ed utilizzo di funzioni protette nel thread manager
    ( chi ha visto hacks di questo tipo sa di cosa parlo ).
Naturalmente il secondo approccio è quello che è( uno schifo ), ma
effettivamente l'ideale sarebbe l'utilizzo di funzioni friend, come in C++
ma per
ottenerlo bisogna mettere entrambi i thread nella stessa unit( cosa che
sinceramente non mi
piace nemmeno un pò, specialmente considerando la natura "diversa" delle due
classi: che
nome dare alla unit? Non mi piace proprio come approccio ).
Un'alternativa ancora potrebbe essere l'uso di pipes, ma questo
aggiungerebbe ancora un
altro livello di complessità ad una cosa già di per se non banale... -_-
Idee? Consigli? Critiche?
Ciao,
-- 
Andrea Raimondi
REICOM S.r.l.
Software Developer
*****************************************************
REICOM S.r.l.
Wireless Technologies
A member of the European Low Power Radio Association.
Società di progettazione di impianti di trasmissione
dati, reti wireless multiservizio per applicazioni
industriali e civili.
-----------------------------------------------------
Via Trieste, 23
35121 - Padova - Italy
Tel: 
+39.049.8763637
Fax: 
+39.049.8784266
Video: 
+39.049.8763618
www.reicom.it
********************************************************

     ( chi ha visto hacks di questo tipo sa di cosa parlo ).
Scusa ma non ho capito moltissimo. Di quante porte stiamo parlando e
perche' le gestisci da thread diversi? APRO, a meno di grosse variazioni
architetturali, gia' alloca tre thread per ciascun componente
TApdComPort.
Cosa deve fare il thread manager un po' piu' in dettaglio? Sai poi che
il thread in cui allochi le ApdComport dovrebbe essere windowed (IIRC).
Hai gia' dato un'occhiata al sito di Paul Breneman?
Infine, se il problema e' effettivamente la comunicazione fra i thread
puoi usare qualcosa di sostanzialmente semplice come una (o piu')
T(String)List protetta da una CriticalSection (o in MultiRead -
ExclusiveWrite, ci deve essere qualcosa nelle JCL) a cui accodi
comandi/risposte.
Ancor piu' semplice e' la comunicazione via messaggi: PostThreadMessage
und so weiter...
Quanto all'amicalita' dei diversi thread non vedo cosa c'entri con il
problema della comunicazione, o meglio, se e' solo per chiamare un
metodo di un thread attualmente idle non esiste il problema. Pero' piu'
probabilmente non ho capito cosa intendi.
Saluti
Paolo Arosio
PS: se vuoi scrivermi in privato l'indirizzo di reply-to
paoloarosio(*)
despammed.com
 e' valido.
-- 
"La dimostrazione dell'esistenza di specie intelligenti nell'universo
 e' che non ci vengono a trovare" [Calvin & Hobbes]

il thread in cui allochi le ApdComport dovrebbe essere windowed (IIRC).
E' questo il punto, Andrea dovrebbe spiegare piu' dettagliatamente quale siano
le necessita' di dialogo tra il main thread gli altri.
L'apdcomport e' gia' di per se' threaded, sfruttandone gli eventi di trigger
(OnTrigger...) si puo' lanciare dei postmessage opprtunamente definiti al main
thread. 
Un mio programma usa una ApdComPort per campionare costantemente via seriale
20 dispositivi differenti che sparano 1 pacchetto ogni secondo.
L'applicazione non ha mai subito rallentamenti e l'unico problema di mancati
sincronismi dei pacchetti in ricezione sono arrivati dalla seriale che ha
dimostrato di avere alcuni problemi di segnali. cambiata la seriale, il
programma ha ripreso a macinare informazioni costantemente, senza mai subire
rallentamenti.
-- 
Morde. 
(
mo...@despammed.com
)
M-List di icld: 
http://it.groups.yahoo.com/group/icld/

Provo a riformulare:
Devo avere un'async su ogni porta, ok?
Per ogni Async esiste un thread che lo contiene, piu' un manager che
gestisce tutti i threads - sia quelli che contengono le Async che altri.
Ok?
Il mio problema è come impostare le cose in modo che tutto "scorra" senza
dover utilizzare tecniche strane come pipes o robe simili.
Insomma il mio dubbio è: meglio usare una struttura ad eventi, oppure il
richiamo di procedure pubbliche o protette del manager da parte degli altri
threads per le notifiche?
Ciao,
Andrea

threads per le notifiche?
Il mio consiglio e' di sfruttare gli eventi (OnTrigger...) di ogni ApdComPort
e di notificarli al main thread con postmessages di messaggi codificati
appositamente. Il MainThread, ricevuto il messaggio, interroghera' tramite
opportuni metodi pubblici il thread che ha generato il messaggio.
Ciao!


 secondo.
Fammi capire, tu usi UN SOLO ApdComPort per pilotare VENTI
dispositivi diversi( un dispositivo per porta )? Come fai?
Ciao,
Andrea

dispositivi diversi( un dispositivo per porta )? Come fai?
No, non piloto nulla, mi pongo in ascolto su una porta seriale e ad ogni
secondo arriva un pacchetto che scompongo poi in 20 diverse informazioni.
Di fatto l'apdcomport e' agganciato ad una sola porta e triggera una volta al
secondo, per sempre, e durante l'esecuzione il programma lavora sul db senza
mai subire rallentamenti.
Mi sembra invece di capire che tu devi *pilotare* 20 dispositivi con 20
apdcomport in 20 thread separati (perche' separati?). Giusto?


 20 apdcomport in 20 thread separati (perche' separati?). Giusto?
Esatto, devo pilotare N dispositivi che devono essere coordinati poi da un
manager centrale... per ora ho risolto con gli eventi, spero funzioni!
Stiamo costruendo una specie di framework, che ci permetta - appunto - di
fare queste cose, in modo da fare il lavoro una volta per poi magari solo
sostituire qualche thread.
Ciao,
Andrea

 funzioni!
Onestamente non vedo ancora la _necessita'_ di avere un (altro) thread
per porta, almeno usando gli Async(*). Hai cogenti necessita' di
processare le informazioni nell'ordine in cui arrivano?
(*) se, per dire, fossero porte tcp-ip gestite con componenti indy la
cosa sarebbe naturale, ma appunto le APRO non sono nate per lavorare in
modalita' bloccante (il lavoro intrinsecamente bloccante lo fanno i
thread gestiti dal dispatcher di basso livello).
Cosa usi come dispositivo hw?
Saluti
Paolo Arosio


 Paolo Arosio
Andrea