J'ai un thread en attente sur un EventWaitHandle (AutoResetEvent):Est-il sûr d'appeler .Close (.Dispose) sur un EventWaitHandle directement après .Set?
AutoResetEvent.WaitOne();
J'ai un autre fil de signalisation le premier fil à continuer
AutoResetEvent.Set();
AutoResetEvent.Close();
Est-il sûr d'appeler .Close directe après .Set, en d'autres termes sera-t-il garanti que le thread d'attente a continué avant que le AutoResetEvent soit éliminé?
Oui, il est sécuritaire si tout se déroule comme décrit dans votre question. Si vous savez que tous les threads attendaient déjà lorsque vous avez appelé set, ces threads auront été signalés et tout ira bien puisque tous les threads en attente sont garantis être libérés avant un appel pour définir des retours.
Cependant, si vous rencontrez une course et un appel et que vous fermez avant que le thread ait commencé à attendre, vous obtiendrez une exception si vous essayez d'attendre. Donc, en pratique, il vaut mieux éviter ce modèle. IMHO
Je pense que vous ne pouvez jamais savoir que les threads attendent. Ils pourraient être désinscrits 1 instruction avant d'entrer dans l'attente et d'autres discussions ne pouvaient pas dire. – usr
Merci pour votre réponse. Donc, j'abandonne ce modèle. J'ai trouvé une implémentation gérée pour un AutoResetEvent, et je pourrais essayer ma chance avec celui-là: http://www.codeproject.com/Articles/244638/Managed-Thread-Synchronization – Edwin
@usr Exactement, c'est pourquoi je pense que c'est un mauvais modèle sur lequel s'appuyer. Je ne connais pas assez le scénario pour recommander une autre solution, mais il pourrait être possible d'implémenter un simple compte à rebours sûr où la vérification des threads et la fermeture des poignées comptent avant de fermer la poignée pour s'assurer que tous les utilisateurs ont terminé leur tâche . Ou simplement inverser les dépendances .. – Niclas
Les [docs pour 'Fermer'] (https://msdn.microsoft.com/en-us/library/system.threading.waithandle.close (v = vs.110) .aspx) disent: _" Une fois que cette méthode est appelée, les références à l'instance en cours provoquent un comportement indéfini. »_ Que ce soit pour de nouvelles références ou que des appels existants comme 'WaitOne' ne soient pas clarifiés. Mais je ne voudrais pas l'essayer ... pourquoi ne pas fermer/disposer de celui qui fait l'attente? –
Parce que l'attente est facultative, donc elle ne sera pas éliminée alors si l'attente n'est pas faite ... – Edwin