Terminaison de thread C # et Thread.Abort ()

Question

Dans la description MSDN de la méthode Thread.Abort (), il reste: "L'appel de cette méthode met généralement fin au thread."

Pourquoi pas toujours?

Dans quels cas ne termine-t-il pas le fil?

Existe-t-il une autre possibilité de terminer les threads?

Cordialement, Lerax.

Answer 1

Thread.Abort() injecte un ThreadAbortException sur le thread. Le fil peut annuler la demande en appelant Thread.ResetAbort(). Aussi, il y a certaines parties du code, comme l' finally bloc à exécuter avant que l'exception est gérée. Si, pour une raison quelconque, le fil est coincé dans un bloc de l'exception ne seront jamais posées sur le fil.

Comme l'appelant a très peu de contrôle sur l'état du thread lors de l'appel d' Abort(), il est généralement conseillé de ne pas le faire. Passer un message dans le thread de demander la résiliation à la place.

Answer 2

Dans lequel cas, il n'est pas arrêter le fil?

Cette question est un doublon.

http://stackoverflow.com/questions/1559255/whats-wrong-with-using-thread-abort/1560567#1560567

Il y a aucune autre possibilité de résilier les threads?

Oui. Votre problème est que vous ne devriez jamais commencer un thread que vous ne pouvez pas dire poliment d'arrêter, et il s'arrête en un temps opportun. Si vous êtes dans une situation où vous avez besoin de lancer un thread qui pourrait être (1) difficile de s'arrêter, (2) buggy, ou pire de tous (3) hostile à l'utilisateur, alors la meilleure chose à faire est de faire un nouveau processus, démarrer le thread dans le nouveau processus, puis terminer le processus lorsque vous souhaitez que le thread pour aller vers le bas. La seule chose qui peut garantir la sécurité de la terminaison d'un thread non coopératif est le système d'exploitation prenant en bas de tout le processus.

Voir mon trop long de répondre à cette question pour plus de détails:

http://stackoverflow.com/questions/2113261/using-lock-statement-within-a-loop-in-c

Pertinentes bit est le bit à la fin où j'ai discuter de ce que les considérations relatives à combien de temps vous devez attendre pour un thread à tuer lui-même avant de l'abandonner.

Answer 3

Pourquoi pas TOUJOURS? Dans lequel cas, il n'est pas termenate le fil?

Pour commencer, un thread peut attraper un ThreadAbortException et annuler sa propre terminaison. Ou il pourrait effectuer un calcul qui prend une éternité alors que vous êtes en train de l'abandonner. De ce fait, le moteur d'exécution ne peut pas garantir que le fil sera toujours terminer une fois que vous lui demandez.

ThreadAbortException a plus:

Lorsqu'un appel est effectué à l'Abandon de méthode pour détruire un thread, le common language runtime jette un ThreadAbortException. ThreadAbortException est une exception spéciale, qui peut être pris, mais il sera automatiquement soulevé de nouveau à la fin du bloc catch. Lorsque cette exception est levée, le moteur d'exécution exécute tous les blocs avant la fin du thread. Depuis le thread peut faire une surabondance de calcul dans les blocs, ou appelez - Thread.ResetAbort() d'annuler l'abandon, il n'y a aucune garantie que le fil ne sera jamais la fin.

Vous n'avez pas besoin d' Abort() un fil manuellement. Le CLR va faire tout le sale boulot pour vous si vous laissez la méthode dans le fil de retour; qui mettra fin à la thread normalement.

Answer 4

FileStream.read à un canal nommé qui ne reçoit actuellement rien (les blocs d'appel lus en attendant les données entrantes) ne répondra pas à Thread.Abort . Il reste à l'intérieur de read() -call.

Answer 5

Que faire si un thread est un verrou et est annulée / tué ? Ressources de rester coincé

Il fonctionne très bien quand un thread appelle abandonner lui-même, mais pas par l'autre thread. Abandonner, avec force se termine le touchés thread, même si elle n'a pas rempli sa tâche et ne fournit aucune l'occasion pour le nettoyage de ressources

référence MSDN

---

voir: Géré Threading les Meilleures Pratiques