[C++] Istanziare thread di tipo produttore e consumatore

[misterx]

caspita che avventura............se lo sapevo avrei scelto la mia tesi in modo differente

Allo stato attuale non avendo ulteriore tempo per approfondire mi vedo costretto a continuare ad usare la CreateThread() pur consapevole di eventuali problematiche che NON annoterò sulla tesi in quanto è orientata ad altro.
Mi sono affossato incontrando tutte queste stranezze di windows che purtroppo aggiungono tempi casuali al mio scopo ultimo che è semplicemente quello di leggere lo stato di n sensori connessi ad una macchina.

C'è un modo, un test, per sincerarsi velocemente di tutte queste problematiche?

Ho lasciato girare i due thread per 48 ore e non ho avuto problemi, forse è fortuna e per curiosità, li ho lasciati girare senza mutex e non ho notato problemi

[shodan]

Originariamente inviato da misterx
caspita che avventura............se lo sapevo avrei scelto la mia tesi in modo differente

E non ho nemmeno accennato ai problemi derivanti da processori multicore che eseguono veramente i thread in parallelo (a differenza di un singlecore che da solo l'impressione di farlo).

Allo stato attuale non avendo ulteriore tempo per approfondire mi vedo costretto a continuare ad usare la CreateThread() pur consapevole di eventuali problematiche che NON annoterò sulla tesi in quanto è orientata ad altro.

A mio avviso il vero problema è usare CreateThread() senza sapere che può dare problemi. Se lo sai, sai anche come agire, altrimenti rischi di passare il tempo cercando di capire perché una strtok() dia di matto (dai memory leak ai numeri del lotto).

Mi sono affossato incontrando tutte queste stranezze di windows che purtroppo aggiungono tempi casuali al mio scopo ultimo che è semplicemente quello di leggere lo stato di n sensori connessi ad una macchina.

Le stranezze di windows sono altre. Tipo: perché l'icona dell'altoparlante è con la crocetta rossa che indica servizio non avviato, quando sento tranquillamente musica? O rete assente se ora sono su Internet?

C'è un modo, un test, per sincerarsi velocemente di tutte queste problematiche?

Che io sappia no. Solo tanta esperienza e molto stress test.

Ho lasciato girare i due thread per 48 ore e non ho avuto problemi, forse è fortuna e per curiosità, li ho lasciati girare senza mutex e non ho notato problemi

La sincronizzazione è necessaria solo se i due thread hanno risorse condivise (variabli globali o device hardware per natura univoci - Per esempio la porta seriale).
Se ogni thread ha le sue variabili su cui lavorare, non si hanno problemi.
La tematica comunque è molto ampia. Impossibile parlarne su un forum.

[misterx]

mi rendo conto della complessità dell'argomento ma mi tocca usare anche il forum per tentare almeno di capirci qualcosa di più.

L'unica cosa che condividono i due thread: uno scrive e l'altro lo legge è un array. L'aver tolto il mutex mi è servito per capire se una eventuale collisione, che nei sistemi monoprocessore per me(sensazione a pelle) non avviene, avrebbe fatto bloccare il mio programma ma così non è stato.

Un progettista mi ha perfino detto: ma che ti frega di sincronizzare i due thread?
Mi frega non tanto per una questione di raffinatezza del codice ma per evitare che il thread che legge i dati li legga per 10 volte consecutive prima di cedere la CPU al thread che li deve manipolare(consumare). 10 letture consecutive inutili sottraggono tempo al thread consumatore e mi porterebbe ad una falsa interpretazione delle tempistiche che sto analizzando.

La cosa strana è che contattato il mio relatore mi ha detto di mettere in attesa in maniera alternata i due thread allo scopo di non avere inconsistenza sui dati ed evitare che windows esegua n volte un thread prima di eseguire l'altro.
Ma a questo punto se un thread attende l'altro non mi conviene evitare la strada dei due thread e scrivere in sequenza

- scrivi array
- leggi array

in un singolo thread?


grazie per tutte le indicazioni

[shodan]

Originariamente inviato da misterx
mi rendo conto della complessità dell'argomento ma mi tocca usare anche il forum per tentare almeno di capirci qualcosa di più.

Rimangono comunque (e non potrebbero essere altrimenti) risposte superficiali.
Anche questo pdf: http://www.iac.rm.cnr.it/sisopii/winthreads.pdf si limita solo a illustrare i concetti generali. Altrimenti occorrono libri.

L'unica cosa che condividono i due thread: uno scrive e l'altro lo legge è un array. L'aver tolto il mutex mi è servito per capire se una eventuale collisione, che nei sistemi monoprocessore per me(sensazione a pelle) non avviene, avrebbe fatto bloccare il mio programma ma così non è stato.

Una race condition non blocca un programma (se intendi crash). Fai in maniera che due thread diversi facciano una delete non sincronizzata su un puntatore e ne riparliamo.
Puoi avere dati inconsistenti, questo si. Ammesso che tu legga e scriva in due thread diversi la stessa cella dell'array. Se ogni thread gestisce una sua singola cella dell'array, non è necessario sincronizzare la cella. E il principio alla base dei Thread Local Storage.

Un progettista mi ha perfino detto: ma che ti frega di sincronizzare i due thread?

Un'affermazione vera o falsa a seconda del contesto. Se usi i TLS può aver ragione.

Mi frega non tanto per una questione di raffinatezza del codice ma per evitare che il thread che legge i dati li legga per 10 volte consecutive prima di cedere la CPU al thread che li deve manipolare(consumare). 10 letture consecutive inutili sottraggono tempo al thread consumatore e mi porterebbe ad una falsa interpretazione delle tempistiche che sto analizzando.

Nulla vieta al SO di schedulare 10 volte consecutive lo stesso thread. Usare un mutex da garanzia di non corrompere i dati, non sulla politica di schedulazione decisa dal SO.

La cosa strana è che contattato il mio relatore mi ha detto di mettere in attesa in maniera alternata i due thread allo scopo di non avere inconsistenza sui dati ed evitare che windows esegua n volte un thread prima di eseguire l'altro.

Perché strano? E' l'idea di fondo della sincronizzazione.

Ma a questo punto se un thread attende l'altro non mi conviene evitare la strada dei due thread e scrivere in sequenza

- scrivi array
- leggi array

in un singolo thread?

Non è detto che un thread attenda all'infinito. Può attendere solo lo stretto necessario alla lettura o scrittura dei dati e passare ad altro.

[misterx]

riferendomi alla tua ultima affermazione:

Non è detto che un thread attenda all'infinito. Può attendere solo lo stretto necessario alla lettura o scrittura dei dati e passare ad altro.

ho notato che è di fatto la schedulazione fatta da windows per (n) volte prima di eseguire il thread consumatore che a mio avviso, ovviamente da profano rende inutile l'uso di un semaforo in quanto non vengono eseguiti i thread in sequenza. La mia situazione attuale è la seguente:


// thread produttore
semaforo rosso
leggo i dati dalla scheda e li scrivo nell'array (in questa fase consumatore non può usare l'array)
semaforo verde


// thread consumatore
semaforo rosso
verifico l'array bit a bit (in questa fase produttore non può usare l'array)
semaforo verde

Se per ipotesi il tempo impiegato da produttore ad eseguire il suo codice è di 1 ms e windows per ragioni sue lo esegue per 10 volte quel ritardo si ripercuote poi su consumatore.

Io ho la necessità di avere tempistiche di esecuzione piuttosto precise.

Detto questo, allora non è meglio che io metta le cose in sequenza in modo che la schedulazione di windows può fare quello che gli pare?

// thread produttore
leggo i dati dalla scheda e li scrivo nell'array

// thread consumatore
verifico l'array bit a bit

in questo senso non mi trovo daccordo col mio relatore.


p.s.
forse tutte queste complicazioni sono lo scotto da pagare quando non si lavora su sistemi real-time?

[misterx]

aggiungo: ho stampato il documento da te allegato ed ho letto in merito alle thread-safe. Cercando in rete poi con google mi è parso di capire che la VCL non è thread-safe

[shodan]

Originariamente inviato da misterx
riferendomi alla tua ultima affermazione:

Non è detto che un thread attenda all'infinito. Può attendere solo lo stretto necessario alla lettura o scrittura dei dati e passare ad altro.

ho notato che è di fatto la schedulazione fatta da windows per (n) volte prima di eseguire il thread consumatore che a mio avviso, ovviamente da profano rende inutile l'uso di un semaforo in quanto non vengono eseguiti i thread in sequenza.

E' proprio perché non vengono eseguiti in sequenza che hai bisogno di un meccanismo di sincronizzazione. Se la schedulazione del SO fosse predicibile sarebbero risolti tutti (o gran parte) dei problemi relativi al multi threading.

La mia situazione attuale è la seguente:

// thread produttore
semaforo rosso
leggo i dati dalla scheda e li scrivo nell'array (in questa fase consumatore non può usare l'array)
semaforo verde


// thread consumatore
semaforo rosso
verifico l'array bit a bit (in questa fase produttore non può usare l'array)
semaforo verde

Se per ipotesi il tempo impiegato da produttore ad eseguire il suo codice è di 1 ms e windows per ragioni sue lo esegue per 10 volte quel ritardo si ripercuote poi su consumatore.
Io ho la necessità di avere tempistiche di esecuzione piuttosto precise.

Come ho già detto non hai garanzie. Per assurdo, il SO può schedulare lo stesso thread all'infinito se gli va. Più terra terra il SO da la garanzia che il thread in attesa prima o poi verrà eseguito. Se poi è fermo su un mutex, semaforo o condition variable, il suo quanto di tempo sarà sospeso e l'esecuzione passa ad un altro thread.
La condizione peggiore è un processore dual core con due thread eseguiti contemporaneamente. Il SO li esegue entrambi, ma accedendo a una sezione critica solo uno dei due eseguirà il suo codice. L'altro rimane fermo finchè il primo non rilascia la sezione critica. Se il primo thread non lo fa, il secondo rimane ad aspettare in eterno.
In ogni caso non si può fare affidamento sull'hardware e SO per predicire l'esecuzione di vari thread.
Se vuoi avere un minimo di garanzie sui tempi devi essere tu a creare le condizioni affinché il thread consumatore inizi a lavorare quando il produttore gli segnala che i dati sono pronti. E quando il consumatore ha finito, deve segnalare al produttore (magari in attesa) che è pronto per elaborare nuovi dati. A quel punto il produttore produce nuovi dati e segnala al consumatore (magari in attesa) che ha dati freschi da elaborare.
Il massimo che puoi fare è dire: metto in attesa in consumatore per 10ms perché sono sicuro che il produttore impiega meno tempo a creare i dati necessari.

Detto questo, allora non è meglio che io metta le cose in sequenza in modo che la schedulazione di windows può fare quello che gli pare?

// thread produttore
leggo i dati dalla scheda e li scrivo nell'array

// thread consumatore
verifico l'array bit a bit

E se il thread consumatore inizia a verificare quando il produttore non ha ancora finito? Ti puoi ritrovare con mezzo array di dati freschi e mezzo con dati vecchi. O peggio, il consumatore può terminare prima che il produttore riesca a produrre dati freschi.

p.s.
forse tutte queste complicazioni sono lo scotto da pagare quando non si lavora su sistemi real-time?

Sarebbe bello verificarlo su un QNX ma i costi sono proibitivi. A naso però credo che sia peggio, molto peggio.

[shodan]

Originariamente inviato da misterx
aggiungo: ho stampato il documento da te allegato ed ho letto in merito alle thread-safe. Cercando in rete poi con google mi è parso di capire che la VCL non è thread-safe

Non uso Borland quindi non so che dirti. LA VCL però è nata per Delphi, quindi se chiedi a qualche esperto di Delphi saprà dirti qualcosa di più. C'è anche il forum di Embarcadero dove potresti chiedere lumi.

[misterx]

perdonami ma mi sono accorto solo ora di aver pensato una cosa e scritta un'altra

ripetendomi:

Detto questo, allora non è meglio che io metta le cose in sequenza in modo che la schedulazione di windows può fare quello che gli pare?

// thread unico
a) leggo i dati dalla scheda e li scrivo nell'array
b) verifico l'array bit a bit

// eventuale thread per la scrittura dei dati su disco

quindi un unico thread produttore/consumatore