gli eventi sono simili agli interrupt, vengono generati in parallelo (salvo che il generatore non sia nello stesso thread del ricevente, in tal caso l discorso salta)
poichè sono in parallelo, tutte le azioni sui dai devono essere sincronizzate;
void serialEvent (Serial ArduinoPort) {
if ( ArduinoPort.available() > 0) {
syncronize(valRX){
valRX = ArduinoPort.readChar();
}
}
in questo caso la variabile valRX viene usata come "blocco", ma attenzione! deve esse un oggetto, e se assegni un nuovo indirizzo alla fariabile usando l'operatore "new" salta tutto! infatti queste variabili di solito sono final (quindi niente "new", ma puoi comunque cambiarne i valori contenuti)
ovvio che poi il blocco va messo anche dove usi la variabile!
c'è una complessità in più come noti. in oltre tra un darw e l'altro, se la grafica è pesante o il pc lento, possono arrivare tanti Event! In fatti di solito si usa un buffer, per esempio una Queue Concurrent, in modo che la gestione della sincronizzazione se la fa java, però lo fa solo finchè usi la queue, nel momento in cui hai ricevuto il dato nulla ti assicura che non succeda nulla al dato.
Un esempio: io ho un mondo fisico e uno grafico, in 2 thread differenti, ed entrambi usano lo stesso array di oggetti da disegnare/muovere.
non posso usare una queue perchè lenta da riempire ogni 60Hz con tutti gli oggetti, e non posso certo fare una sincronize sulla posizione del singolo oggetto, perchè non posso disegnare metà schermo quando un oggetto è al loop fisico 1 e alcuno al loop fisico 2. In questo caso ho usato una variabile di lock ad inizio dei 2 loop, quindi se sta funzionando un loop, l'altro rimane in attesa. Appena finisco di assegnare le posizioni rilascio il lock e proseguo in altre operazioni dei loop in parallelo. notare che può capitare più loop video senza loop fisico, e viceversa, questo slega molto la qualità della visualizzazione video dalla velocità di esecuzione della logica di gioco, però come hai notato aumenta la complessità: pensa se diemntico una sincronize!!