Newsgroup: it.comp.programmare.win32
Titolo: malcomprensione sulla EnterCriticalSection()

ciao,
credevo di saper usare la EnterCriticalSection(), invece no, 
evidentemente...
se io proteggo un zona di codice tra una
EnterCriticalSection
e una
LeaveCriticalSection
e ho un secondo task che usa delle variabili utilizzate dentro il primo 
pezzo di codice con le enter-leave,
che succede? io credevo che se il controllo era al primo task il secondo 
task si fermasse piuttosto che
accedere alle variabili in comune...invece a quanto pare no..
domanda: se ho delle subroutine dentro la zona enter-leave, e le subroutine 
usano le variabili in questione,
la cosa funziona lo stesso o dovrei rifare la coppia enter-leave nelle 
subroutine?
TASK 1
EnterCriticalSection
sub1(); // usa la var pippo cambiandola
LeaveCriticalSection
TASK2
pippo = 3
non so se mi sono spiegato, ma pensavo di bloccare il secondo task e 
lavorare solo col primo,
invece il secondo task gira e mi tocca le variabili!!
come posso freezarlo?
ciao
GCL 

 wrote in message
news:hP7wh.1227$wO2...@tornado.fastwebnet.it...


 protetta x assegnarci valori
ho risolto, era una cavolta mia,  mancava la EnterCriticalSection dall'altra 
parte,
pero' la tua osservazione resta valida, quindi
domanda:  come posso "freezare" un task?
GCL

 ha scritto nel messaggio 
news:TGhwh.1700$wO2...@tornado.fastwebnet.it...


 mi rispondo da solo: SuspendThread() e ResumeThread()
Fai molta attenzione nell'utilizzare queste API che, salvo casi molto 
particolari, non servono.
Se sospendi un thread non puoi sapere cosa sta facendo quando lo 
sospendi e che cosa aveva in uso al momento della sospensione.
Se, per fare un caso semplice, il thread era dentro una critical 
section, tutti i thread che usano la stessa critical section saranno 
bloccati fino a che tu non fai la resume del thread. Ovviamente se il 
thread che deve fare il resume passa per la critical section tutto si 
ferma.
Questo problema è già complesso da gestire dentro il tuo codice e 
diventa maledettamente complicato se coinvolge librerie (che potrebbero 
usare critical section o altri sistemi di sincronizazione dentro le 
loro funzioni) o le API di Windows (che in alcuni casi potrebbero 
sincronizzarsi internamente).
In sintesi, forse (molto probablmente) se spieghi meglio il tuo 
problema si può trovare una soluzione che non richieda l'uso del 
meccanismo di suspend/resume dei thread.
-- 
Valter Minute
(the reply address of this message is invalid)
(l'indirizzo di reply di questo messaggio non è valido)

 wrote in message
news:Xns98CA68DC719...@193.43.96.1...


 tutte mutex-sincronizzate
Lo stesso vale per le critical section AFAIK.
I mutex sono meno performanti perchč, a differenza delle CS, prevedono 
un passaggio in kernel mode. Quindi utilizzare un mutex non cambia di 
molto la situazione ma puň rallentare l'esecuzione del programma (anche 
se non ci sono "collisioni" nell'accesso all'oggetto.
-- 
Valter Minute
(the reply address of this message is invalid)
(l'indirizzo di reply di questo messaggio non č valido)

 meccanismo di suspend/resume dei thread.
il mio problema e' sempre il solito: ho un PC (poi sara' una scheda con CE, 
per ora sto simulando su XP)
ed ho tre thread:
- uno legge da seriale e carica un buffer circolare
- un secondo legge il buffer circolare e interpreta i comandi dati/ricevuti 
da una smartcard
      per ora non avevo messo nessuna critical section, tranne che col 
thread seriale
- thread principale (main) che gestisce video, pulsantiera e audio
di solito non ho interazioni tra main e smartcard ma c'e' un comando di 
visualizzazione dati da smartcard che siccome usa il video
ho (colpa mia) messo nel main ed accede alla smartcard, che sarebbe 
prerogativa del thread di servizio.
Casino...
La smartcard (standard ISO 7816) rende due caratteri in base ai quali il 
thread di servizio esegue i suoi compiti,
i caratteri vanno in sw[0] e sw[1] (globali) e determinano le azioni del 
thread di servizio,
peccato che mettendo la lettura nel main la smartcard risponde al main 
dentro sw[0] e sw[1],
il main cerca di rispondere ma il thread di servizio arriva prima, vede sw[] 
e gli frega i dati e parte con la elaborazione
mentre era il main a dover visualizzare a video un messaggio.
Allora ho risolto al volo sospendendo il thread di servizio prima di usare 
impropriamente il main per accedere alla smartcard.
Funziona tutto, mi sto chiedendo se genero dei dead lock... parrebbe di 
no...non ho EnterCriticalSection nel main...
La cosa furba sarebbe spostare tutto nel thread di servizio e settare un 
flag se il main deve visualizzare un messaggio...
bye
GCL 

 settare un flag se il main deve visualizzare un messaggio...
Io userei la critical_section nel main o, meglio, se si può, farei una 
funzione che torna il dato e ripulisce il buffer sw all'interno di una 
critical section. In questo modo chi va a leggere il dato è sicuro che 
nessuno ci acceda o lo ri-elabori in seguito.
Il fatto che il suspend funziona su quel PC non ti garantisce che 
funzionerà sempre. Qualsiasi cosa che alteri i tempi di schedulazione 
potrebbe generare una sospensione del thread in un momento diverso da 
quello (quelli) in cui capita sul tuo sistema e generare un patatrac!


quello (quelli) in cui capita sul tuo sistema e generare un patatrac!
tipo su win CE??  :-))
bye
GCL

 tipo su win CE??  :-))
Esatto.
Ma anche su XP con un hardware più lento/veloce, carico diverso della 
CPU e altri mille fattori.


 Non rischia di incasinarsi con quello di servizio?
no, il thread della seriale e' banale, fa la
 if(!ReadFile(sCommHandleAAMS, byte, 1, &numRxBytes, NULL) || (numRxBytes != 
1))
di cui avevamo parlato in precedenza e se trova dati li mette in un buffer, 
poi Sleep(10) e avanti..
(devo ancora cambiarlo con la waitCommEvent, tipo come farei in VB...)
il thread di servizio deve interpretare i dati in arrivo ricostruendo i 
pacchetti secondo lo standard ISO 7816
e produce token di dati (= comandi), che poi processa. Peccato che un 
comando coinvolga il video, che e'
gestito dal main...da cui il casino di oggi, che ho "risolto" freezando un 
task...
bye
GCL

 freezando un task...
Ok, pensavo che fosse il thread della seriale a fare il parsing e che 
il thread di servizio processasse direttamente i pacchetti.
