C# Durée de vie des objets Thread

Question

Supposons que j'ai un code comme suit :

int Main()
{
    if (true)
    {
       new Thread(()=>
          {
              doSomeLengthyOperation();
          }).Start();
    }
    while (true)
    {
       //do nothing
    }
}

Il y a 2 threads, je vais appeler le thread principal, le thread qui exécute la fonction Main(), et le thread qui se trouve à l'intérieur du test "if" comme Thread A.

Ma question est la suivante : quand le fil A est-il détruit ? La fonction doSomeLenghtyOperation() pourra-t-elle être exécutée jusqu'à son terme ?

Étant donné qu'aucune référence ne pointe vers le fil A, celui-ci sera-t-il marqué comme candidat à la collecte des déchets ?

1. Immédiatement après la fin de l'instruction "new Thread().Start()" elle-même ?
2. Immédiatement après la sortie de l'étendue "if(true)" ?
3. Après la fin de l'exécution de doSomeLengthOperation() ?
4. Jamais ?

Dans tous les exemples que je vois, Main() conserve la référence, puis le thread principal attend de rejoindre le thread A avant de se terminer. Je suis curieux de savoir quelle est la durée de vie du code ci-dessus.

Merci d'avance !

Answer 1

En Thread sera éligible à la collecte des déchets dès qu'il ne sera plus utilisé, c'est-à-dire immédiatement après l'appel de la fonction Start méthode. (Elle ne sera toutefois pas collectée immédiatement, car le ramasseur de déchets s'exécute à des moments précis).

Cependant, le fil de discussion actuel ne repose pas sur l'approche de l'UE. Thread et continuera à fonctionner même si l'objet Thread est collecté.

Si le thread est toujours en cours d'exécution lorsque la méthode principale se termine, l'application ne se terminera pas tant que le thread ne sera pas terminé, à moins que vous n'ayez marqué le thread comme étant un thread d'arrière-plan.

Answer 2

Le mot "fil" peut signifier plusieurs choses ici :

• objet System.Threading.Thread (créé par new Thread() ),
• thread CLR (thread géré),
• thread OS (thread non géré).

L'objet Thread sera candidat à la GC dès que la méthode Start() sera terminée, car il n'y a plus de références à cet objet.

Le thread géré restera en vie pendant l'exécution de doSomeLengthyOperation().

En citant le article par James Kovacs, Microsoft MVP :

La durée de vie d'un thread géré est indépendante de l'objet Thread qui qui le crée, une très bonne chose étant donné que vous ne voudriez pas que le GC mette fin à un thread qui est toujours travail simplement parce que vous avez perdu tous les références à l'objet Thread associé. associé. Ainsi, le GC collecte l'objet l'objet Thread, mais pas le véritable thread géré.

L'article contient également quelques exemples de code utiles si vous souhaitez faire vos propres expériences.

En théorie, les threads du système d'exploitation n'ont pas de relation univoque avec les threads gérés. Extrait de MSDN :

...un hôte sophistiqué peut utiliser l'API d'hébergement CLR pour planifier de nombreux threads gérés sur le même thread de système d'exploitation, ou pour déplacer un thread géré entre différents threads de système d'exploitation.

En pratique, cependant, le fil CLR correspond directement à un fil de discussion sur Windows aujourd'hui .

Answer 3

Quand est-ce que le fil A est détruit ?

Quand doSomeLengthyOperation finitions.

La fonction doSomeLenghtyOperation() pourra-t-elle être exécutée jusqu'à son terme ?

Oui, même si le fil principal existe parce que ce n'est pas un fil de fond. Si vous définissez l'option IsBackground à la propriété true avant de démarrer le thread, si le thread principal existe, ce thread sera également arrêté.

Answer 4

C'est une excellente question ! Le fil finira sûrement et vous pouvez l'essayer vous-même. Mais cela peut devenir intéressant si vous appelez GC.Collect() pendant ce temps. D'après le C# de Richter via CLR, il sera collecté par les ordures.

UPDATE

Je pense qu'il ne sera pas collecté par Garbage Collect puisque Thread.CurrentThread le garde en mémoire en ayant une référence.