Cómo sustituir en tiempo de ejecución el Waithandele que debe esperar un hilo

Question

Me pregunto cómo cambiar de forma segura en el tiempo de ejecución del EventwAithandle que debe esperar un hilo.

Supongamos, por ejemplo, que hay dos hilos (A y C) que están sincronizados a través de eventos. A hace su trabajo cíclicamente y c espera hasta que reciba una notificación de A que puede comenzar a hacer su trabajo (por ejemplo, por el AutoresElevent). El patrón es A-C-A-C ...

Más adelante en un nuevo hilo (b) se inicia (por ejemplo, mediante acción del usuario) y su trabajo debe ejecutarse entre los dos hilos preexistente de esta manera: A hace su trabajo, luego las señales B y una vez b terminan las señales de TI. . Ahora el patrón es abcabc ...

Así que antes de que el hilo c estuviera esperando en el Eventwaithandele compartido con un y más tarde, debería haber un mecanismo seguro que hace que C espera en otro EventwAithandle compartido con B. Me parece que la parte complicada está sustituyendo el evento, usado por C, Dado que, una vez hecho esto, debería poder iniciar fácilmente B, que usará un eventwAithandle para esperar en un trabajo y una eventualidad para que se indique el trabajo. El mecanismo también debe proporcionar una manera de desmontar de manera segura el hilo B y volver a la situación inicial donde solo el hilo A y C están funcionando.

¿Hay una forma segura de lograr esto con EventwAithandle? Si no, cualquier otra sugerencia sería apreciada.

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.