C# fin des Threads et du Fil.Abort()

Dans MSDN, la description de la Thread.Méthode Abort() dit: "l'Appel de cette méthode généralement s'arrête le thread."

Pourquoi pas TOUJOURS?

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

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

InformationsquelleAutor user101375 | 2010-02-12
  1. 57

    Thread.Abort() injecte une ThreadAbortException sur le fil. Le fil peut annuler la demande en appelant Thread.ResetAbort(). Aussi, il y a certaines parties du code, comme 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.

    Que l'appelant a très peu de contrôle sur l'état du thread lors de l'appel de 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.

    • Quel genre de message? Voulez-vous dire une méthode invokation?
    • Cela dépend de combien vous transmettre les données entre votre fils. E. g. si votre thread un thread de travail avec une tâche de la file d'attente, vous pouvez faire la queue un PleaseTerminate message et laisser le fil de la poignée gracieusement.
    • Mon fils a un gros problème de mât être résolus, ont est pas une tâche de la file d'attente.
    • Comme je l'ai dit, cela dépend de votre code de thread est conçu. Vous pourriez peut-être du signal par l'intermédiaire d'un membre de la variable. Il est difficile d'être plus précis sans le code réel disponible.
    InformationsquelleAutor Brian Rasmussen
  2. 52

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

    Cette question est un doublon.

    Quel est le problème avec l'aide de Fil.Abort()

    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:

    Utilisez la fonction de verrouillage de la déclaration dans une boucle en 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.

    • Eric, comment dois-je poliment à un thread de s'arrêter si le thread est en attente sur un objet de synchronisation, par exemple EventWaitHandle.WaitOne();?
    • le contrat entre les deux fils qui décrit comment un thread est à communiquer avec l'autre est pour les auteurs du code qui s'exécute sur les threads. Si vous avez des exigences que (1) un thread X doit attendre sur un objet potentiellement pour toujours, et (2) que le thread Y doit être en mesure à proprement arrêt à visser X dans une quantité limitée de temps, alors je pense que vous avez des exigences contradictoires; décident qui gagne un. Si l'ancien, puis vissez Y va avoir à attendre. Si ce dernier, puis visser X ne devrait pas être en attente pour toujours, il faut attendre une petite quantité de temps.
    • Merci de répondre. Considérer l'architecture suivante: j'ai une application qui a pour minimiser lui-même lorsqu'un système à l'échelle de l'événement se produit. J'ai un fil dans cette application qui attend un nommé global de l'événement et fait son travail quand cet événement est défini. De l'autre côté, ma demande peut-être quitter avant que l'événement se produit, d'avoir à fermer que le thread en attente. Qu'est-ce que le samouraï manière de coder une telle chose?
    • Vous pourriez avoir une boucle qui attend (avec un court délai d'attente) pour l'événement, puis vérifie si il devrait arrêter d'essayer d'attente (de sorte qu'il peut quitter normalement). De cette façon, vous pouvez signaler votre thread qu'il devrait arrêter, et vous ne devriez avoir à attendre aussi longtemps que votre délai d'attente pour qu'il s'arrête.
    • si vous faites ce thread en attente d'un thread d'arrière-plan, alors vous ne devriez pas avoir à le fermer avant de l'application se ferme.
    InformationsquelleAutor Eric Lippert
  3. 17

    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() pour annuler l'abandon, il n'y a aucune garantie que le fil ne sera jamais la fin.

    Vous n'avez pas besoin de 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.

    • J'ai besoin d'Abort (), parce que d'une boucle de message commencé sur ce thread (Répartiteur.Run();). Si je comprends bien correct, j'ai besoin d'Appeler une méthode de l'appel de retour dans le thread pour le terminer?
    InformationsquelleAutor John Feminella
  4. 6

    FileStream.Read() à un canal nommé qui n'est actuellement pas recevoir quoi que ce soit (lire l'appel des blocs lors de l'attente pour l'entrée de données) ne permettra pas de répondre à Thread.Abort(). Il reste à l'intérieur de la Read() appel.

    InformationsquelleAutor jovain
  5. 5

    Que 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é Filetage Meilleures Pratiques

    InformationsquelleAutor Asad Butt
  6. 4

    ThreadAborts ne va pas se produire à l'intérieur d'un bloc finally ou entre BeginCriticalRegion et EndCriticalRegion

    InformationsquelleAutor Rob Fonseca-Ensor
  7. 4

    Je n'arrive pas à interrompre un thread qui est coincé dans une boucle:

    //immortal
Thread th1 = new Thread(() => { while (true) {}});

    Je peux toutefois interrompre le thread si dort pendant la boucle:

    //mortal
Thread th2 = new Thread(() => { while (true) { Thread.Sleep(1000); }});
    • ce ne semble pas être vrai, j'ai couru un programme de test:`{var th = new Thread(() => { int i = 0; try { while (true) { i++; } } catch(Exception e) { Console.WriteLine("l'abandon de@ {0}", i); } }); th.Start(); Thread.Sleep(1000); th.Abort(); th.Join(); }
    InformationsquelleAutor Colin
  8. 3

    Parce que vous pouvez attraper le ThreadAbortException et appel Thread.ResetAbort à l'intérieur du gestionnaire.

    InformationsquelleAutor erikkallen
  9. 0

    OT: Pour une approche globale, indépendant de la langue, particulièrement utile et sacrément drôle de prendre sur la concurrence, voir Verity Stob!

    InformationsquelleAutor Pontus Gagge
  10. -1

    J'ai eu des cas où le fil a été trop occupé pour entendre la Abort() appel, ce qui entraîne généralement une ThreadAbortingException d'être jeté à mon code.

    InformationsquelleAutor Andy Shellam