Thread Appelant.Abandon sur un fil à partir d'un pool de threads

Mon collègue est à l'aide d'un tiers .NET à la bibliothèque pour laquelle nous n'avons pas le code source. Nous sommes à l'aide d'un pool de threads pour avoir beaucoup de threads d'appel dans cette bibliothèque, et, occasionnellement, l'un des fils va juste s'accrocher éternellement tandis que le reste d'entre eux gaiement souffler le long.

Si nous voulons utiliser le redoutable Thread.Abort à tuer de tels fils. J'ai fait ça avant, lorsqu'on fait tourner mon propre fils, mais je n'ai jamais utilisé un pool de threads. Si nous suivons les heures de début de chaque tâche comme ceci:

static Dictionary<Thread, DateTime> started = new Dictionary<Thread, DateTime>();

static void DoSomeWork(object foo)
{
    lock(started)
        started[Thread.CurrentThread] = DateTime.Now;

    SomeBuggyLibraryThatMightInfiniteLoopOrSomething.callSomeFunction(doo);

    lock(started)
        started.Remove(Thread.CurrentThread);
}

alors que l'on peut verrouiller et itérer sur les threads en cours d'exécution et d'appel Thread.Abort de le tuer? Et si nous le faisons, alors nous avons besoin d'ajouter un nouveau thread pour le pool de threads pour remplacer celui que l'on vient de tuer, ou le pool de threads poignée pour nous?

EDIT: je suis très conscient de tous les problèmes potentiels avec Thread.Abort. Je sais que l'idéal est de ne jamais être utilisé dans la production de code, et qu'il n'est pas nécessairement le même arrêter le fil, et que si vous interrompre un thread alors que le thread a acquis un verrou, puis vous pouvez raccrocher les autres threads, etc. Mais pour l'instant, nous sommes sur un échéancier serré et nous avons décent des raisons de croire que dans ce cas particulier, on peut appeler Thread.Abort sans mettre l'ensemble du processus en danger, et nous aimerions éviter d'avoir à réécrire ce programme afin d'éliminer le pool de threads à moins que nous devons absolument.

Donc ce que je veux savoir, c'est ceci: étant donné que nous ALLONS appeler Thread.Abort sur un thread qui appartient à un pool de threads, sont des problèmes causés par ces cours de pool de threads les threads, et nous n'avons manuellement à lancer un nouveau thread pour remplacer celui qui a été tué, ou le pool de threads faire cela pour nous?

"[L'abandon d'un pool de threads thread] est périlleux, cependant. Par le temps que la notification est reçue, et le thread est interrompu, l'original de l'élément de travail pourrait avoir déjà fini, tels que le pool de thread déjà passés à un autre élément de travail. Vous serait l'abandon du secondaire d'élément de travail plutôt que de le désirer, à vous ouvrir à un monde de souffrance. "- Stephen Toub, MSDN Magazine n ° 06-03

OriginalL'auteur Eli Courtwright | 2010-02-25

  1. 9

    Non, vous ne devriez pas appeler à l'Abandon sur les threads du pool de threads. Mon test, il semble que le pool de threads n'recréer les threads si vous l'abandonnez - je abandonnée 1000 pool de threads et il travaillait encore. Je ne sais pas si vous devez vous appuyer sur ce comportement, mais peut-être que vous pouvez sortir avec elle dans ce cas. En général, bien que l'utilisation de Fil.Avorter n'est pas la bonne façon de le faire.

    La bonne façon d'appeler une fonction que vous ne faites pas confiance à bien se comporter est de démarrer dans un nouveau processus et de tuer le processus, si nécessaire.

    Vous ne devez pas appeler Fil.Abandon sur normal threads. Pour commencer, Fil.Avorter n'est même pas garanti à mettre fin à la discussion. Même si elle n'a réussi à interrompre le fil, vous ne savez pas ce gâchis, vous avez laissé derrière ou comment le nettoyer. Vous pourriez vous retrouver avec undisposed ressources. C'est vraiment pas une bonne idée.
    -1. Désolé, j'ai l'habitude de ne pas downvote réponses dont les intentions sont bonnes, mais Eli clairement le sait que Thread.Abort est mal et a demandé si la situation était toute différente (plus mal) avec le pool de threads. Il suffit de répéter l' (bien connu) fait que Thread.Abort est le mal et ne l'aide pas, ne s'agit-il de répondre à la question (c'est à dire si un pool de threads thread sera de retour à la piscine, au bout d'un Fil.Abort).
    Si le buggylibrary est un .NET de l'assemblée, on pourrait supposer qu'il n'est pas prévu pour être lancé dans un nouveau processus. Si vous êtes vraiment paranoïaque, il va s'accrocher à votre application, vous pouvez faire les threads d'arrière-plan, ou même le mettre dans un nouveau domaine d'application
    Désolé, mais je pense que cela devait être dit par quelqu'un. Même si cette réponse est trop tard pour aider les OP, j'espère que cela aide quelqu'un d'autre.
    Je comprends votre point, et j'aime ton edit. -1 changé à +1. 🙂

    OriginalL'auteur Mark Byers

  2. 5

    L'utilisation de Fil.Avorter n'est pas conseillé, car il peut laisser votre demande dans un état non valide. La raison pour cela est que lorsque exigeant un thread à l'avortement, une exception peut être soulevée dans presque n'importe quel endroit possible que la 3ème partie de la bibliothèque. Il est possible qu'il existe des segments de code qui ne sont pas écrites pour être en mesure de faire face à ces abandons asynchrones.

    Ainsi, alors qu'il n'est généralement pas conseillé d'abandonner les threads, il y a des hôtes qui sont très agressifs dans l'abandon de threads. L'un d'eux est ASP.NET. Lorsqu'une requête est trop longue, il annulera le thread pour vous. Donc, avec cela à l'esprit, c'est bête à dire "ne jamais abandonner fils".

    Je vous conseille de trouver où ce code se bloque (la trace de la pile de ThreadAbortException devrait vous donner beaucoup d'informations). Si ça bloque toujours au même endroit (c'est probablement une impasse), trouver avec Réflecteur si l'abandon d'un thread à ce point sera en partie l'état de la corruption. Avec cette information, vous pouvez peut-être déjà de résoudre le problème (peut-être que vous verrou sur un objet de la bibliothèque) ou envoyer un mail à l'auteur de la bibliothèque. Si tout cela ne vous aide pas et vous le voyez, il n'y a pas un risque de l'abandonner, d'être pragmatique et de le tuer 🙂

    Cependant, si il y a un changement de l'état de la corruption, vous devriez essayer d'aller avec une Marque Byers réponse. C'est: essayez d'exécuter cette bibliothèque dans son propre domaine d'application. De cette façon, vous pouvez décharger complète du domaine d'application et il n'y a pas de changement dans les affecter votre application.

    Merci pour l'analyse. Donc, si je fais appel Thread.Abandon sur un pool de threads thread, alors j'ai besoin de créer un nouveau thread pour le remplacer, ou le pool de threads voir que le fil est sorti et en créer un nouveau automatiquement?
    Je viens d'ouvrir un Réflecteur pour voir ce qu'il se passe à l'intérieur du pool de threads, mais il n'est pas clair pour moi. Je soupçonne que le avorté fils de simplement retourner le pool de threads, mais je ne suis pas sûr. Il ne sera pas difficile de le vérifier. Créer un grand nombre de threads que le sommeil et abandonner ceux et de voir si le pool de threads commence à lancer des exceptions ou renvoie la valeur false.

    OriginalL'auteur Steven

  3. 3

    À clarifier ce que la Marque dit, si vous appelez Fil.Annuler vous n'avez aucune idée de l'endroit où il s'arrêtera dans la 3ème partie de la composante en raison de la nature particulière de la ThreadAbortException - il pu laisser un FileStream ouvert par exemple.

    Je serais personnellement créer les Threads moi-même, référencé dans un IList ou de la File d'attente (comme le ThreadPool est mieux adapté pour le feu et l'oublie ou WaitHandles), et en fonction de si vous pensez que l'abandon d'un thread à l'aide de la 3ème partie de la composante n'est pas dangereux, Abort.

    Si vous pensez que l'abandon peut laisser la 3ème partie de la bibliothèque dans un état inacceptable, Rejoindre les fils qui n'ont pas terminé un par un, après un laps de temps à l'aide d'un System.Threading.Timer

    Sinon

    Pour coller avec l'aide de pool de threads, vous pouvez utiliser cette Smart Pool De Threads à la place.

    OriginalL'auteur Chris S

  4. 3

    Lire 'Abortable Thread Pool' par Stephen Toub.
    Il fournit le code source pour un abortable pool de threads. C'est une lecture intéressante.

    Il appelle son propre callback 'HandleItem" lorsque la mise en attente du pool de threads. À l'intérieur de 'HandleItem' il exécute alors la réelle rappel, après l'ajout de la thread en cours d'un dictionnaire de la liste à l'intérieur de sa classe wrapper. 

    ThreadPool.QueueUserWorkItem(new WaitCallback(HandleItem));

HandleItem(...) {
...
_threads.Add(item, Thread.CurrentThread);
...
}

    Il utilise un Dictionnaire de Lier son WorkItems Fils, lorsqu'un utilisateur souhaite annuler un thread il fait un coup d'oeil et annule ce thread particulier.

    Dictionary<WorkItem, Thread>() _threads = New Dictionary<WorkItem, Thread>();

    http://msdn.microsoft.com/en-us/magazine/cc163644.aspx

    OriginalL'auteur

  5. 1

    Vous avez une autre option (que je prendrais si j'avais une journée libre en face de moi):

    désosser le composant de tiers à l'aide de réflecteur et effectivement corriger le blocage d'appels pour en faire asynchroneous.

    Je suis d'accord que ce serait une meilleure solution, mais malheureusement, nous n'avons pas le temps pour ça maintenant. Peut-être alors ce projet est plus.
    Je pense que vous pourriez être en cours d'exécution dans une condition de concurrence dans la 3ème partie du code. Pouvez-vous essayer de faire des appels à l'API et mutuellement exclusives?
    Parce que les appels dans cette bibliothèque à partir d'autres threads continuer à travailler, je suppose que c'est un problème de réseau. Comme un socket a été configuré pour ne jamais le temps, ou peut-être que ça en boucle d'attente pour une entrée à partir de la wacky protocole réseau propriétaire, qu'il utilise. Et nous avons vraiment besoin d'être simultanément en cours d'exécution beaucoup de threads simultanément, puisque nous sommes simultanément connecter à plusieurs ordinateurs sur notre intranet de l'entreprise.

    OriginalL'auteur Florian Doyon