Objets AutoResetEvent et COM

Question

J'ai remarqué que AutoResetEvent gèle complètement la boucle de message (parfois) quand il est au milieu d'un appel WaitOne(), bloquant même le message de signal.

IE:

1. (IU) Nouveau fil donné naissance à
2. (UI) Code appelle WaitOne(); délai d'attente: 10s
3. (T2) Fil ouvre dispositif, les appels Set()
4. (UI) blocs WaitOne boucle messages
5. (UI) délai de WaitOne écoulé, l'exécution de code continue
6. (UI) Fenêtre principale reçoit le signal et continue (mais WaitOne a échoué)

Des idées?

EDIT: ajout d'UI/T2 pour spécifier les unités d'exécution. En outre, j'essaie de transformer une bibliothèque tierce en synchrone. L'ouverture de périphériques implique un appel Open() qui à son tour engendre un événement OpenOK ou OpenFailed, j'essaye de faire un appel booléen Open() qui renvoie true/false en fonction de l'événement engendré.

Answer 1

... efficacement bloquant même le message du signal.

Vous ne pouvez pas "bloquer l'envoi d'un signal", vous pouvez seulement empêcher l'autre thread d'arriver au réglage de l'événement. Les poignées d'attente ne nécessitent aucune pompe à message. La seule chose à laquelle je peux penser est que l'objet COM en question est lié au thread de l'interface utilisateur. L'accès à l'objet COM peut être tenté d'invoquer de retour de T2 vers le thread d'interface utilisateur qui attend que T2 fasse quelque chose (interblocage). Pour voir si c'est effectivement le problème assurez-vous que vous ne créez pas ou n'accédez pas à l'objet COM sur le thread UI.

Answer 2

Ceci est le résultat d'une condition de concurrence. Le problème est que l'étape 3 peut se produire avant l'étape 2, car ils sont sur des threads différents. Parce que vous utilisez un AutoResetEvent, au moment où WaitOne est appelé, l'événement est déjà réinitialisé.

En raison de ce problème, lorsque cela est possible, j'essaie généralement d'éviter AutoResetEvents en faveur de ManualResetEvents.

L'ordre des événements avec un ManualResetEvent serait (j'ai énuméré 2 cas comme 2a et 2b pour démontrer que leur ordre de fonctionnement ne soit pas garantie):

1. une nouvelle discussion Engendré
2. a. Le thread d'origine appelle WaitOne(); b. Nouveaux appels de thread Set();
3. Le fil d'origine se réveille.
4. Appels de threads d'origine Reset();

Answer 3

Vous trouverez peut-this publier SO sur "En attendant le mainthread tout en continuant à traiter"
Existe aussi Calling Synchronous Methods Asynchronously de MSDN