Come sostituire in fase di esecuzione il waithandle che un thread dovrebbe aspettare

Question

Mi chiedo come cambiare in modo sicuro in fase di esecuzione l'eventwaithandle che un filo dovrebbe aspettare.

Supponiamo ad esempio che ci sono due fili (A e C) che sono sincronizzati attraverso EventWaitHandles. A fa il suo lavoro ciclicamente e c aspetta fino a quando non riceve una notifica da un che può iniziare a fare il suo lavoro (ad esempio per l'autoresetevent). Il modello è A-C-A-C ...

Successivamente viene lanciato un nuovo thread (B) (ad es. Per azione dell'utente) e il suo lavoro deve essere eseguito tra i due fili preesistenti in questo modo: A fa il suo lavoro, quindi segnali B e una volta B finisce i segnali c . Ora il modello è ABCABC ...

Prima del thread c stava aspettando sull'eventwaithandle condiviso con un e in seguito dovrebbe esserci un meccanismo sicuro che rende c in attesa di un altro eventwaithandle condiviso con B. Mi sembra che la parte difficile stia sostituendo l'eventwaithandle utilizzato da C, Dalla volta che questo è fatto, dovrei essere facilmente in grado di lanciare B che utilizzerà un eventwaithandle per aspettare un lavoro e un eventwaithandle per segnalare il lavoro C. Il meccanismo dovrebbe anche fornire un modo per svuotare in modo sicuro il filo B e per tornare alla situazione iniziale in cui solo il filo A e C sta funzionando.

C'è un modo sicuro per realizzare questo con EventWaithandle? In caso contrario, nessun altro suggerimento sarebbe apprezzato.

Answer 1

If task A knows about the change, then have task C own the event. Task A signals task C's event if C is to be next, or task B's event if task B is to be next.

Alternatively, use the same mechanism as for changing any other shared data: acquire a mutex across all accesses to the handle. e.g. task C acquires the lock, reads the handle, releases the lock, waits on the handle. To change it you have the UI thread acquire the lock, change the handle, release the lock.

Answer 2

Have you thought about implementing some sort of scheduler where the threads can register (deregister) with a handle to start and to signal completion. And the scheduler then takes care of starting the next thread by setting the appropriate start-event and continues with the next thread, when the previous one has set the completion event.