Produttore/consumatore per parlare seriamente ai dispositivi

Question

Ecco il mio problema: devo essere in grado di inviare e ricevere su un dispositivo su seriale. Questo deve essere fatto in modo multi-thread. Il flusso è la seguente:

1. Attendere dispositivo di mandarmi qualcosa - o se inattiva, poi interrogare lo stato per vedere se sono in linea con il dispositivo

2. Se il dispositivo mi invia qualcosa, allora il messaggio processo, riconoscere e comunica al dispositivo di eseguire altri comandi, se necessario

In questo momento, ho ricevuto un thread e trasmetto thread. Il thread di ricezione ha un ciclo while che continua a controllare la porta seriale tramite ReadFile (...) per un byte. Se ho un byte, quindi inizio a costruire il mio buffer e poi analizzo i dati per determinare cosa mi è stato inviato.

Il thread di invio accetta il comando successivo definito dal thread di lettura e lo invia tramite WriteFile alla stessa porta COM. La chiave è che esiste una relazione di ricezione/invio tra me e il dispositivo.

La mia domanda è: ho un modello nidificato produttore/consumatore qui? Se il mio thread di ricezione sta consumando dal dispositivo e il thread di invio sta producendo sul dispositivo, i thread devono necessariamente parlare in modo che siano sincronizzati, giusto? Qual è il modo migliore per sincronizzare i miei sforzi in modo efficiente e rapido per parlare al dispositivo? Nota: sto usando C++ Builder 5 che ha TThreads e può utilizzare sezioni e mutex critici.

Modifica: sto anche utilizzando il polling, quindi sono aperto a utilizzare anche WaitCommEvent se funzionerà meglio!

Answer 1

Quali risorse stai condividendo che pensi di dover sincronizzare?

Se si ha qualcosa come una coda tra i due thread, allora si tratta di un modello produttore/consumatore piuttosto classico. PER ESEMPIO. Se si ha solo una lettura del thread e poi si mettono i comandi in coda mentre un altro thread estrae dalla coda, elabora il comando e scrive sul dispositivo, allora è necessario sincronizzare l'accesso alla coda con un mutex o semaforo.

Forse mi manca qualcosa ma questo dovrebbe essere complicato solo se si hanno più thread che leggono dalla coda e i comandi che devono essere trasmessi devono rimanere in ordine. Quindi cerca di mantenerlo semplice.