Comment se substituer au moment de l'exécution le waithandle qu'un fil devrait attendre

Question

Je me demande comment changer en toute sécurité au moment de l'exécution l'événementWaithandle qu'un fil devrait attendre.

Supposons par exemple qu'il existe deux threads (A et C) synchronisés par des événements. A fait son travail cycliquement et c attend jusqu'à ce qu'il reçoive une notification de A d'autant qu'il peut commencer à faire son travail (par exemple par les autorestites. Le motif est A-C-A-C ...

Plus tard sur un nouveau thread (B) est lancé (par exemple par l'action de l'utilisateur) et son travail doit être exécuté entre les deux threads préexistants de la manière suivante: A fait son travail, puis signale B et une fois B FINDES IT SIGNAION C . Maintenant, le motif est abcabc ...

Donc avant que le fil c'était une attente sur l'événementwaithandle partagé avec A et plus tard, il devrait y avoir un mécanisme de sécurité qui fait que C attente sur un autre événement partagé avec B. Il me semble que la partie délicate substitue l'événement utilisé par C, Étant donné qu'une fois que cela est fait, je devrais facilement pouvoir lancer B qui utilisera un événementWaithandle pour attendre sur un emploi et un événementWaithandle pour signaler le travail C. Le mécanisme devrait également fournir un moyen de démonter en toute sécurité le fil B et de revenir à la situation initiale où seul le fil a et c fonctionne.

Y a-t-il un moyen sûr de l'accomplir avec Eventwaithandle? Sinon, aucune autre suggestion serait appréciée.

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.