Stavo discutendo con un compagno di squadra sul blocco in .NET. È un ragazzo davvero brillante con una vasta esperienza sia nella programmazione di livello inferiore che di livello superiore, ma la sua esperienza con la programmazione di livello inferiore supera di gran lunga la mia. Ad ogni modo, ha sostenuto che il blocco di .NET dovrebbe essere evitato su sistemi critici che dovrebbero essere sottoposti a carichi pesanti, per quanto possibile, al fine di evitare la piccola possibilità di un "thread zombi" che si schianta contro un sistema. Uso abitualmente il blocco e non sapevo cosa fosse un "filo zombi", quindi ho chiesto. L'impressione che ho avuto dalla sua spiegazione è che un thread di zombi è un thread che è terminato ma che in qualche modo mantiene ancora alcune risorse. Un esempio di come un thread di zombi potrebbe rompere un sistema è stato un thread che inizia una procedura dopo aver bloccato un oggetto, e poi viene a un certo punto terminato prima che il blocco possa essere rilasciato. Questa situazione ha il potenziale per arrestare il sistema in modo anomalo, perché alla fine, i tentativi di eseguire quel metodo comporteranno tutti i thread in attesa dell'accesso a un oggetto che non verrà mai restituito, perché il thread che utilizza l'oggetto bloccato è morto.

Penso di averne capito il senso, ma se sono fuori base, per favore fatemelo sapere. Il concetto aveva senso per me. Non ero del tutto convinto che questo fosse uno scenario reale che poteva accadere in .NET. Non ho mai sentito parlare di "zombi", ma riconosco che i programmatori che hanno lavorato in modo approfondito ai livelli più bassi tendono ad avere una comprensione più profonda dei fondamenti dell'informatica (come il threading). Sicuramente vedo il valore del blocco, tuttavia, e ho visto molti programmatori di livello mondiale sfruttare il blocco. Ho anche una capacità limitata di valutarlo da solo perché so che l' lock(obj)affermazione è davvero solo zucchero sintattico per:

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

e perché Monitor.Entere Monitor.Exitsono contrassegnati extern. Sembra ipotizzabile che .NET esegua un qualche tipo di elaborazione che protegge i thread dall'esposizione a componenti di sistema che potrebbero avere questo tipo di impatto, ma che è puramente speculativo e probabilmente basato solo sul fatto che non ho mai sentito parlare di "thread zombi" prima. Quindi, spero di poter ottenere un feedback su questo qui:

1. Esiste una definizione più chiara di "filo zombi" rispetto a quella che ho spiegato qui?
2. I thread di zombi possono verificarsi su .NET? (Perché perché no?)
3. Se applicabile, come potrei forzare la creazione di un thread zombi in .NET?
4. Se applicabile, come posso sfruttare il blocco senza rischiare uno scenario di thread zombi in .NET?

Aggiornare

Ho fatto questa domanda poco più di due anni fa. Oggi è successo:

• Esiste una definizione più chiara di "filo zombi" rispetto a quella che ho spiegato qui?

Mi sembra una spiegazione abbastanza buona per me - un thread che è terminato (e quindi non può più rilasciare alcuna risorsa), ma le cui risorse (ad esempio handle) sono ancora in giro e (potenzialmente) causando problemi.

• I thread di zombi possono verificarsi su .NET? (Perché perché no?)
• Se applicabile, come potrei forzare la creazione di un thread zombi in .NET?

Sicuramente lo fanno, senti, ne ho creato uno!

[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);
    }
}

Questo programma avvia un thread Targetche apre un file e poi si uccide immediatamente usando ExitThread. Il thread zombie risultante non rilascerà mai l'handle nel file "test.txt" e quindi il file rimarrà aperto fino al termine del programma (è possibile verificare con Process Explorer o simili). L'handle di "test.txt" non verrà rilasciato fino a quando non GC.Collectviene chiamato - si scopre che è ancora più difficile di quanto pensassi di creare un thread di zombi che perde maniglie)

• Se applicabile, come posso sfruttare il blocco senza rischiare uno scenario di thread zombi in .NET?

Non fare quello che ho appena fatto!

Finché il codice viene ripulito correttamente dopo se stesso (utilizzare Maniglie sicure o classi equivalenti se si lavora con risorse non gestite) e finché non si fa di tutto per uccidere i thread in modi strani e meravigliosi (il modo più sicuro è solo per non uccidere mai i thread - lasciateli terminare normalmente, o attraverso eccezioni se necessario), l'unico modo per avere qualcosa che assomigli a un thread di zombi è se qualcosa è andato molto storto (ad esempio qualcosa va storto nel CLR).

In realtà è sorprendentemente difficile creare un thread di zombi (ho dovuto P / Invocare in una funzione che ti dice in modo essenziale nella documentazione di non chiamarlo al di fuori di C). Ad esempio il seguente codice (terribile) in realtà non crea un thread di zombi.

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);
}

Nonostante abbia commesso degli errori terribili, l'handle di "test.txt" è ancora chiuso non appena Abortviene chiamato (come parte del finalizzatore per il filequale sotto le copertine utilizza SafeFileHandle per avvolgere l'handle del file)

L'esempio di blocco nella risposta di C.Evenhuis è probabilmente il modo più semplice per non rilasciare una risorsa (un blocco in questo caso) quando un thread viene terminato in un modo non strano, ma questo può essere risolto facilmente usando lockinvece un'istruzione, oppure mettendo il finallyblocco in un blocco.

Guarda anche

• Sottigliezze di codegen C # IL per un caso molto sottile in cui un'eccezione può impedire il rilascio di un blocco anche quando si utilizza la lockparola chiave (ma solo in .Net 3.5 e precedenti)
• I blocchi e le eccezioni non si mescolano

Ho ripulito un po 'la mia risposta, ma ho lasciato quello originale di seguito come riferimento

È la prima volta che sento parlare del termine zombi, quindi suppongo che la sua definizione sia:

Un thread che è terminato senza rilasciare tutte le sue risorse

Quindi, data questa definizione, quindi sì, puoi farlo in .NET, come con altri linguaggi (C / C ++, java).

Tuttavia , non penso che questo sia un buon motivo per non scrivere un codice thread-mission-critical in .NET. Potrebbero esserci altri motivi per decidere contro .NET, ma cancellarlo solo perché in qualche modo puoi avere thread di zombi non ha senso per me. I thread di zombi sono possibili in C / C ++ (direi anche che è molto più facile sbagliare in C) e molte app critiche e thread sono in C / C ++ (trading ad alto volume, database ecc.).

Conclusione Se stai per decidere una lingua da usare, ti suggerisco di prendere in considerazione il quadro generale: prestazioni, abilità di squadra, pianificazione, integrazione con app esistenti ecc. Certo, i thread di zombi sono qualcosa a cui dovresti pensare , ma dal momento che è davvero difficile fare questo errore in .NET rispetto ad altri linguaggi come C, penso che questa preoccupazione sarà oscurata da altre cose come quelle sopra menzionate. In bocca al lupo!

La risposta originale Zombies ^† può esistere se non scrivi il codice di threading corretto. Lo stesso vale per altri linguaggi come C / C ++ e Java. Ma questo non è un motivo per non scrivere codice threaded in .NET.

E proprio come con qualsiasi altra lingua, conoscere il prezzo prima di utilizzare qualcosa. Aiuta anche a sapere cosa sta succedendo sotto il cofano in modo da poter prevedere eventuali problemi.

Il codice affidabile per i sistemi mission critical non è facile da scrivere, qualunque sia la lingua in cui ti trovi. Ma sono certo che non sia impossibile farlo correttamente in .NET. Anche AFAIK, il threading .NET non è così diverso dal threading in C / C ++, utilizza (o è costruito da) le stesse chiamate di sistema ad eccezione di alcuni costrutti specifici .net (come le versioni leggere di RWL e le classi di eventi).

^{† la} _{prima volta che ho sentito parlare del termine zombi, ma in base alla tua descrizione, il tuo collega probabilmente intendeva un thread terminato senza rilasciare tutte le risorse. Ciò potrebbe potenzialmente causare un deadlock, una perdita di memoria o qualche altro effetto collaterale negativo. Questo ovviamente non è desiderabile, ma individuare .NET a causa di questa possibilità non è probabilmente una buona idea poiché è possibile anche in altre lingue. Direi anche che è più facile sbagliare in C / C ++ che in .NET (specialmente in C dove non hai RAII) ma molte app critiche sono scritte in C / C ++ giusto? Quindi dipende davvero dalle tue circostanze individuali. Se vuoi estrarre ogni oncia di velocità dalla tua applicazione e vuoi avvicinarti il ​​più possibile al bare metal, .NET potrebbenon essere la soluzione migliore. Se hai un budget limitato e fai molte interfacce con i servizi web / le librerie .net esistenti / ecc. NET potrebbe essere una buona scelta.}

In questo momento la maggior parte della mia risposta è stata corretta dai commenti qui sotto. Non eliminerò la risposta perché ho bisogno dei punti reputazione perché le informazioni nei commenti possono essere preziose per i lettori.

Immortal Blue ha sottolineato che in .NET 2.0 e versioni successive i finallyblocchi sono immuni alle interruzioni del thread. E come commentato da Andreas Niedermair, questo potrebbe non essere un vero thread di zombi, ma il seguente esempio mostra come interrompere un thread può causare problemi:

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");
    }
}

Tuttavia, quando si utilizza un lock() { }blocco, finallyverrà comunque eseguito quando un ThreadAbortExceptionviene sparato in quel modo.

Le seguenti informazioni, a quanto pare, sono valide solo per .NET 1 e .NET 1.1:

Se all'interno del lock() { }blocco si verifica un'altra eccezione e ThreadAbortExceptionarriva esattamente quando il finallyblocco sta per essere eseguito, il blocco non viene rilasciato. Come hai detto, il lock() { }blocco è compilato come:

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

Se un altro thread chiama Thread.Abort()all'interno del finallyblocco generato , il blocco potrebbe non essere rilasciato.

Non si tratta dei thread di Zombie, ma il libro Effective C # ha una sezione sull'implementazione di IDisposable, (articolo 17), che parla di oggetti di Zombie che pensavo potessi trovare interessanti.

Consiglio di leggere il libro stesso, ma l'essenza di questo è che se hai una classe che implementa IDisposable o che contiene un descrittore, l'unica cosa che dovresti fare in entrambi è il rilascio di risorse. Se fai altre cose qui, allora c'è la possibilità che l'oggetto non venga raccolto, ma non sarà accessibile in alcun modo.

Fornisce un esempio simile al seguente:

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

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

Quando viene chiamato il distruttore su questo oggetto, un riferimento a se stesso viene inserito nell'elenco globale, il che significa che rimane vivo e in memoria per la durata del programma, ma non è accessibile. Ciò può significare che le risorse (in particolare le risorse non gestite) potrebbero non essere completamente rilasciate, il che può causare ogni sorta di potenziali problemi.

Un esempio più completo è di seguito. Quando viene raggiunto il ciclo foreach, ci sono 150 oggetti nell'elenco Non morti che contengono ciascuno un'immagine, ma l'immagine è stata GC'd e si ottiene un'eccezione se si tenta di utilizzarla. In questo esempio, ricevo ArgumentException (il parametro non è valido) quando provo a fare qualsiasi cosa con l'immagine, sia che provi a salvarla, sia a visualizzare dimensioni come altezza e larghezza:

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);
    }
}

Ancora una volta, sono consapevole che stavi chiedendo in particolare dei thread di zombi, ma il titolo della domanda riguarda gli zombi in .net, e mi è stato ricordato questo e ho pensato che altri potrebbero trovarlo interessante!

Sui sistemi critici sottoposti a carichi pesanti, la scrittura di codice senza blocco è migliore principalmente a causa dei miglioramenti delle prestazioni. Guarda cose come LMAX e come sfrutta la "simpatia meccanica" per grandi discussioni su questo. Preoccupati per i fili di zombi però? Penso che sia un caso limite che è solo un bug da appianare, e non un buon motivo per non usarlo lock.

Sembra più che il tuo amico stia solo immaginando e ostentando la sua conoscenza dell'oscura terminologia esotica per me! Durante tutto il periodo in cui gestivo i laboratori di performance di Microsoft UK, non ho mai incontrato un'istanza di questo problema in .NET.

1. Esiste una definizione più chiara di "filo zombi" rispetto a quella che ho spiegato qui?

Sono d'accordo che esistono "Discussioni di zombi", è un termine che si riferisce a ciò che accade con le discussioni che sono lasciate con risorse che non lasciano andare e che tuttavia non muoiono completamente, da cui il nome "zombi", quindi il tuo la spiegazione di questo rinvio è piuttosto giusta per i soldi!

2. Possono esserci thread di zombi su .NET? (Perché perché no?)

Sì, possono verificarsi. È un riferimento e in realtà indicato da Windows come "zombie": MSDN utilizza la parola "Zombie" per processi / thread morti

Accadere spesso è un'altra storia, e dipende dalle tue tecniche e pratiche di codifica, come per te che ti piace il Thread Locking e lo hai fatto per un po ', non mi preoccuperei nemmeno di quello scenario che ti sta accadendo.

E sì, come @KevinPanko ha giustamente menzionato nei commenti, "Zombie Threads" proviene da Unix, motivo per cui vengono utilizzati in XCode-ObjectiveC e indicati come "NSZombie" e utilizzati per il debug. Si comporta più o meno allo stesso modo ... l'unica differenza è che un oggetto che sarebbe dovuto morire diventa uno "ZombieObject" per il debug invece del "Zombie Thread" che potrebbe essere un potenziale problema nel tuo codice.

Sono in grado di creare thread di zombi abbastanza facilmente.

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

Ciò perde le maniglie del filo (per Join() ). È solo un'altra perdita di memoria per quanto riguarda il mondo gestito.

Ora, uccidere un thread in un modo che detiene effettivamente le serrature è un dolore nella parte posteriore, ma possibile. L'altro ExitThread()fa il lavoro. Come ha scoperto, l'handle del file è stato ripulito dal gc ma locknon lo farebbe attorno a un oggetto. Ma perché dovresti farlo?