J'avais une discussion avec un coéquipier sur le verrouillage en .NET. C'est un gars très brillant avec une vaste expérience dans la programmation de niveau inférieur et supérieur, mais son expérience avec la programmation de niveau inférieur dépasse de loin la mienne. Quoi qu'il en soit, il a fait valoir que le verrouillage .NET devrait être évité sur les systèmes critiques censés être soumis à une charge élevée si possible afin d'éviter la possibilité certes faible d'un «fil zombie» de planter un système. J'utilise régulièrement le verrouillage et je ne savais pas ce qu'était un «fil zombie», alors j'ai demandé. L'impression que j'ai eue de son explication est qu'un fil zombie est un fil qui s'est terminé mais qui conserve en quelque sorte encore certaines ressources. Un exemple qu'il a donné de la façon dont un fil zombie pourrait briser un système si un fil commence une procédure après avoir verrouillé un objet, puis se termine à un moment donné avant que le verrou puisse être libéré. Cette situation a le potentiel de planter le système, car en fin de compte, les tentatives d'exécution de cette méthode entraîneront tous les threads en attente d'accès à un objet qui ne sera jamais renvoyé, car le thread qui utilise l'objet verrouillé est mort.

Je pense que j'ai compris l'essentiel, mais si je suis hors de la base, faites-le moi savoir. Le concept avait du sens pour moi. Je n'étais pas complètement convaincu qu'il s'agissait d'un scénario réel qui pourrait se produire dans .NET. Je n'ai jamais entendu parler de "zombies", mais je reconnais que les programmeurs qui ont travaillé en profondeur à des niveaux inférieurs ont tendance à avoir une compréhension plus approfondie des principes fondamentaux de l'informatique (comme le filetage). Cependant, je vois vraiment la valeur du verrouillage, et j'ai vu de nombreux programmeurs de classe mondiale tirer parti du verrouillage. J'ai également une capacité limitée à évaluer cela par moi-même parce que je sais que l' lock(obj)énoncé est vraiment juste du sucre syntaxique pour:

bool lockWasTaken = false;
var temp = obj;
try { Monitor.Enter(temp, ref lockWasTaken); { body } }
finally { if (lockWasTaken) Monitor.Exit(temp); }

et parce que Monitor.Enteret Monitor.Exitsont marqués extern. Il semble concevable que .NET fasse une sorte de traitement qui protège les threads de l'exposition aux composants du système qui pourraient avoir ce genre d'impact, mais c'est purement spéculatif et probablement juste basé sur le fait que je n'ai jamais entendu parler de "threads zombies" avant. J'espère donc pouvoir obtenir des commentaires à ce sujet ici:

1. Existe-t-il une définition plus claire d'un "fil zombie" que ce que j'ai expliqué ici?
2. Les threads zombies peuvent-ils se produire sur .NET? (Pourquoi pourquoi pas?)
3. Le cas échéant, comment pourrais-je forcer la création d'un fil zombie dans .NET?
4. Le cas échéant, comment puis-je tirer parti du verrouillage sans risquer un scénario de thread zombie dans .NET?

Mise à jour

J'ai posé cette question il y a un peu plus de deux ans. Aujourd'hui, c'est arrivé:

• Existe-t-il une définition plus claire d'un "fil zombie" que ce que j'ai expliqué ici?

Cela me semble être une assez bonne explication - un thread qui s'est terminé (et ne peut donc plus libérer de ressources), mais dont les ressources (par exemple les poignées) sont toujours présentes et (potentiellement) causent des problèmes.

• Les threads zombies peuvent-ils se produire sur .NET? (Pourquoi pourquoi pas?)
• Le cas échéant, comment pourrais-je forcer la création d'un fil zombie dans .NET?

Ils le font, regardez, j'en ai fait un!

[DllImport("kernel32.dll")]
private static extern void ExitThread(uint dwExitCode);

static void Main(string[] args)
{
    new Thread(Target).Start();
    Console.ReadLine();
}

private static void Target()
{
    using (var file = File.Open("test.txt", FileMode.OpenOrCreate))
    {
        ExitThread(0);
    }
}

Ce programme démarre un thread Targetqui ouvre un fichier, puis se tue immédiatement en utilisant ExitThread. Le thread zombie résultant ne relâchera jamais la poignée vers le fichier "test.txt" et donc le fichier restera ouvert jusqu'à la fin du programme (vous pouvez vérifier avec l'explorateur de processus ou similaire). Le handle de "test.txt" ne sera pas libéré avant l' GC.Collectappel - il s'avère que c'est encore plus difficile que je ne le pensais de créer un thread zombie qui fuit les poignées)

• Le cas échéant, comment puis-je tirer parti du verrouillage sans risquer un scénario de thread zombie dans .NET?

Ne fais pas ce que je viens de faire!

Tant que votre code se nettoie correctement après lui-même (utilisez des poignées sûres ou des classes équivalentes si vous travaillez avec des ressources non gérées), et tant que vous ne faites pas de votre mieux pour tuer les threads de manière étrange et merveilleuse (la manière la plus sûre est simplement de ne jamais tuer des fils - les laisser se terminent normalement, ou par des exceptions si nécessaire), la seule façon que vous allez avoir quelque chose qui ressemble à un fil de zombie est si quelque chose est allé très mal (par exemple , quelque chose va mal dans le CLR).

En fait, il est en fait étonnamment difficile de créer un fil zombie (j'ai dû P / Invoke dans une fonction qui vous dit essentiellement dans la documentation de ne pas l'appeler en dehors de C). Par exemple, le code (horrible) suivant ne crée en fait pas de fil zombie.

static void Main(string[] args)
{
    var thread = new Thread(Target);
    thread.Start();
    // Ugh, never call Abort...
    thread.Abort();
    Console.ReadLine();
}

private static void Target()
{
    // Ouch, open file which isn't closed...
    var file = File.Open("test.txt", FileMode.OpenOrCreate);
    while (true)
    {
        Thread.Sleep(1);
    }
    GC.KeepAlive(file);
}

Malgré quelques erreurs assez horribles, le handle de "test.txt" est toujours fermé dès qu'il Abortest appelé (dans le cadre du finaliseur pour filelequel, sous les couvertures, utilise SafeFileHandle pour envelopper son handle de fichier)

L'exemple de verrouillage dans la réponse de C.Evenhuis est probablement le moyen le plus simple de ne pas libérer une ressource (un verrou dans ce cas) lorsqu'un thread se termine de manière non bizarre, mais cela peut être facilement résolu en utilisant une lockinstruction à la place, ou mettre la libération dans un finallybloc.

Voir également

• Subtilités de code C # IL pour un cas très subtil où une exception peut empêcher la libération d'un verrou même lors de l'utilisation du lockmot clé (mais uniquement dans .Net 3.5 et versions antérieures)
• Les verrous et les exceptions ne se mélangent pas

J'ai un peu nettoyé ma réponse, mais j'ai laissé l'original ci-dessous pour référence

C'est la première fois que j'entends parler du terme zombies, donc je suppose que sa définition est:

Un thread qui s'est terminé sans libérer toutes ses ressources

Donc, étant donné cette définition, alors oui, vous pouvez le faire dans .NET, comme avec d'autres langages (C / C ++, java).

Cependant , je ne pense pas que ce soit une bonne raison de ne pas écrire de code critique et fileté dans .NET. Il peut y avoir d'autres raisons de décider contre .NET, mais annuler .NET simplement parce que vous pouvez avoir des fils zombies n'a pas de sens pour moi. Les threads zombies sont possibles en C / C ++ (je dirais même qu'il est beaucoup plus facile de gâcher en C) et beaucoup d'applications critiques et filetées sont en C / C ++ (trading à volume élevé, bases de données, etc.).

Conclusion Si vous êtes en train de décider d'une langue à utiliser, je vous suggère de prendre en considération la situation dans son ensemble: performances, compétences d'équipe, calendrier, intégration avec les applications existantes, etc. Bien sûr, les fils de zombies sont quelque chose que vous devriez penser , mais comme il est si difficile de faire cette erreur dans .NET par rapport à d'autres langages comme C, je pense que cette préoccupation sera éclipsée par d'autres choses comme celles mentionnées ci-dessus. Bonne chance!

La réponse originale Zombies ^† peut exister si vous n'écrivez pas le bon code de thread. La même chose est vraie pour d'autres langages comme C / C ++ et Java. Mais ce n'est pas une raison pour ne pas écrire de code threadé dans .NET.

Et comme pour toute autre langue, sachez le prix avant d'utiliser quelque chose. Il permet également de savoir ce qui se passe sous le capot afin de prévoir tout problème potentiel.

Le code fiable pour les systèmes critiques n'est pas facile à écrire, quelle que soit la langue dans laquelle vous vous trouvez. Mais je suis certain qu'il n'est pas impossible de le faire correctement en .NET. De plus, AFAIK, le threading .NET n'est pas si différent du threading en C / C ++, il utilise (ou est construit à partir de) les mêmes appels système, à l'exception de certaines constructions spécifiques à .net (comme les versions légères de RWL et les classes d'événements).

^{† La} _{première fois que j'ai entendu parler du terme zombies, mais d'après votre description, votre collègue voulait probablement dire un fil qui s'est terminé sans libérer toutes les ressources. Cela pourrait potentiellement provoquer un blocage, une fuite de mémoire ou d'autres effets secondaires néfastes. Ce n'est évidemment pas souhaitable, mais isoler .NET à cause de cette possibilité n'est probablement pas une bonne idée car c'est également possible dans d'autres langues. Je dirais même qu'il est plus facile de gâcher en C / C ++ qu'en .NET (surtout en C où vous n'avez pas RAII) mais beaucoup d'applications critiques sont écrites en C / C ++, n'est-ce pas? Cela dépend donc vraiment de votre situation personnelle. Si vous souhaitez extraire chaque once de vitesse de votre application et vous rapprocher le plus possible du bare metal, alors .NET peutne pas être la meilleure solution. Si vous avez un budget serré et que vous faites beaucoup d'interfaçage avec les services Web / les bibliothèques .net existantes / etc., alors .NET peut être un bon choix.}

À l'heure actuelle, la plupart de ma réponse a été corrigée par les commentaires ci-dessous. Je ne supprimerai pas la réponse car j'ai besoin des points de réputation car les informations contenues dans les commentaires peuvent être utiles aux lecteurs.

Immortal Blue a souligné que dans .NET 2.0 et les finallyblocs supérieurs sont immunisés contre les abandons de threads. Et comme l'a commenté Andreas Niedermair, il ne s'agit peut-être pas d'un véritable thread zombie, mais l'exemple suivant montre comment l'interruption d'un thread peut provoquer des problèmes:

class Program
{
    static readonly object _lock = new object();

    static void Main(string[] args)
    {
        Thread thread = new Thread(new ThreadStart(Zombie));
        thread.Start();
        Thread.Sleep(500);
        thread.Abort();

        Monitor.Enter(_lock);
        Console.WriteLine("Main entered");
        Console.ReadKey();
    }

    static void Zombie()
    {
        Monitor.Enter(_lock);
        Console.WriteLine("Zombie entered");
        Thread.Sleep(1000);
        Monitor.Exit(_lock);
        Console.WriteLine("Zombie exited");
    }
}

Cependant, lors de l'utilisation d'un lock() { }bloc, le finallyserait toujours exécuté quand un ThreadAbortExceptionest tiré de cette façon.

Il s'avère que les informations suivantes ne sont valables que pour .NET 1 et .NET 1.1:

Si à l'intérieur du lock() { }bloc, une autre exception se produit et ThreadAbortExceptionarrive exactement au moment où le finallybloc est sur le point d'être exécuté, le verrou n'est pas libéré. Comme vous l'avez mentionné, le lock() { }bloc est compilé comme suit:

finally 
{
    if (lockWasTaken) 
        Monitor.Exit(temp); 
}

Si un autre thread appelle Thread.Abort()à l'intérieur du finallybloc généré , le verrou peut ne pas être libéré.

Il ne s'agit pas de threads Zombie, mais le livre Effective C # a une section sur l'implémentation d'IDisposable, (article 17), qui parle des objets Zombie que je pensais que vous pourriez trouver intéressants.

Je recommande de lire le livre lui-même, mais l'essentiel est que si vous avez une classe implémentant IDisposable ou contenant un Desctructor, la seule chose que vous devriez faire dans l'un ou l'autre est de libérer des ressources. Si vous faites d'autres choses ici, il est possible que l'objet ne soit pas récupéré, mais qu'il ne soit pas accessible de quelque manière que ce soit.

Il donne un exemple similaire à ci-dessous:

internal class Zombie
{
    private static readonly List<Zombie> _undead = new List<Zombie>();

    ~Zombie()
    {
        _undead.Add(this);
    }
}

Lorsque le destructeur sur cet objet est appelé, une référence à lui-même est placée sur la liste globale, ce qui signifie qu'il reste en vie et en mémoire pendant la durée de vie du programme, mais n'est pas accessible. Cela peut signifier que les ressources (en particulier les ressources non gérées) peuvent ne pas être entièrement libérées, ce qui peut provoquer toutes sortes de problèmes potentiels.

Un exemple plus complet est ci-dessous. Au moment où la boucle foreach est atteinte, vous avez 150 objets dans la liste des morts-vivants contenant chacun une image, mais l'image a été GC'd et vous obtenez une exception si vous essayez de l'utiliser. Dans cet exemple, j'obtiens une ArgumentException (le paramètre n'est pas valide) lorsque j'essaie de faire quoi que ce soit avec l'image, que j'essaie de l'enregistrer ou même d'afficher des dimensions telles que la hauteur et la largeur:

class Program
{
    static void Main(string[] args)
    {
        for (var i = 0; i < 150; i++)
        {
            CreateImage();
        }

        GC.Collect();

        //Something to do while the GC runs
        FindPrimeNumber(1000000);

        foreach (var zombie in Zombie.Undead)
        {
            //object is still accessable, image isn't
            zombie.Image.Save(@"C:\temp\x.png");
        }

        Console.ReadLine();
    }

    //Borrowed from here
    //http://stackoverflow.com/a/13001749/969613
    public static long FindPrimeNumber(int n)
    {
        int count = 0;
        long a = 2;
        while (count < n)
        {
            long b = 2;
            int prime = 1;// to check if found a prime
            while (b * b <= a)
            {
                if (a % b == 0)
                {
                    prime = 0;
                    break;
                }
                b++;
            }
            if (prime > 0)
                count++;
            a++;
        }
        return (--a);
    }

    private static void CreateImage()
    {
        var zombie = new Zombie(new Bitmap(@"C:\temp\a.png"));
        zombie.Image.Save(@"C:\temp\b.png");
    }
}

internal class Zombie
{
    public static readonly List<Zombie> Undead = new List<Zombie>();

    public Zombie(Image image)
    {
        Image = image;
    }

    public Image Image { get; private set; }

    ~Zombie()
    {
        Undead.Add(this);
    }
}

Encore une fois, je sais que vous posiez des questions sur les fils de zombies en particulier, mais le titre de la question concerne les zombies dans .net, et cela m'a rappelé et j'ai pensé que d'autres pourraient le trouver intéressant!

Sur les systèmes critiques sous forte charge, l'écriture de code sans verrouillage est préférable, principalement en raison des améliorations des performances. Regardez des trucs comme LMAX et comment il exploite la "sympathie mécanique" pour de grandes discussions à ce sujet. Mais vous vous inquiétez des fils de zombies? Je pense que c'est un cas de bord qui est juste un bug à résoudre, et ce n'est pas une raison suffisante pour ne pas l'utiliser lock.

On dirait plus que votre ami est juste fantaisiste et affiche sa connaissance de la terminologie exotique obscure pour moi! Pendant tout le temps où je dirigeais les laboratoires de performances de Microsoft UK, je n'ai jamais rencontré d'instance de ce problème dans .NET.

1.Y a-t-il une définition plus claire d'un "fil zombie" que ce que j'ai expliqué ici?

Je suis d'accord sur le fait que "Threads Zombie" existe, c'est un terme pour désigner ce qui se passe avec les Threads qui se retrouvent avec des ressources qu'ils ne lâchent pas et qui ne meurent pas complètement, d'où le nom "zombie", donc votre l'explication de cette référence est assez juste sur l'argent!

2.Les threads zombies peuvent-ils se produire sur .NET? (Pourquoi pourquoi pas?)

Oui, ils peuvent se produire. C'est une référence, et en fait référencé par Windows comme "zombie": MSDN utilise le mot "Zombie" pour les processus / threads morts

Se produire fréquemment, c'est une autre histoire, et dépend de vos techniques et pratiques de codage, comme pour vous qui aimez Thread Locking et qui l'ont fait depuis un moment, je ne m'inquiéterais même pas de ce scénario qui vous arrive.

Et oui, comme @KevinPanko l'a correctement mentionné dans les commentaires, "Zombie Threads" vient d'Unix, c'est pourquoi ils sont utilisés dans XCode-ObjectiveC et appelés "NSZombie" et utilisés pour le débogage. Il se comporte à peu près de la même manière ... la seule différence est qu'un objet qui aurait dû mourir devient un "ZombieObject" pour le débogage au lieu du "Zombie Thread" qui pourrait être un problème potentiel dans votre code.

Je peux faire des fils zombies assez facilement.

var zombies = new List<Thread>();
while(true)
{
    var th = new Thread(()=>{});
    th.Start();
    zombies.Add(th);
}

Cela fuit les poignées de fil (pour Join()). C'est juste une autre fuite de mémoire en ce qui nous concerne dans le monde géré.

Maintenant, tuer un fil de manière à ce qu'il retienne réellement les verrous est une douleur à l'arrière mais possible. L'autre gars ExitThread()fait le boulot. Comme il l'a découvert, le descripteur de fichier a été nettoyé par le GC, mais pas lockautour d'un objet. Mais pourquoi voudriez-vous faire ça?