Suspension et reprise des threads
Mise à jour : novembre 2007
Les façons les plus courantes de synchroniser les activités de threads consistent à bloquer et à diffuser des chemins ou à verrouiller des objets ou des régions de code. Pour plus d'informations sur ces verrouillage et blocage des mécanismes, consultez Vue d'ensemble des primitives de synchronisation.
Vous pouvez également avoir des threads en veille. Lorsque les threads sont bloqués ou en veille, vous pouvez utiliser un ThreadInterruptedException pour interrompre la mise en attente.
Méthode Thread.Sleep
L'appel de la méthode Thread.Sleep entraîne le blocage immédiat du thread en cours pendant le temps, en millisecondes, que vous passez à Thread.Sleep, cédant le reste de sa tranche de temps à un autre thread. Un thread ne peut pas appeler Thread.Sleep sur un autre thread.
Un appel Thread.Sleep avec Timeout.Infinite entraîne la mise en veille d'un thread jusqu'à ce qu'elle soit interrompue par un autre thread qui appelle Thread.Interrupt ou jusqu'à ce qu'elle soit terminée par Thread.Abort.
Interruption de threads
Vous pouvez interrompre un thread en attente en faisant appel à Thread.Interrupt sur le thread bloqué pour lever une ThreadInterruptedException qui sort le thread de l'appel bloquant. Le thread doit intercepter ThreadInterruptedException et faire tout ce qu'il faut pour continuer à travailler. Si le thread ignore l'exception, le runtime intercepte l'exception et arrête le thread.
.gif "Remarque") Remarque : |
|---|
Si le thread cible n'est pas bloqué lors de l'appel à Thread.Interrupt, l'interruption n'a lieu qu'au moment du blocage. Si le thread ne se bloque jamais, il peut poursuivre jusqu'à la fin sans être jamais interrompu. |
Si une attente est une attente managée, Thread.Interrupt et Thread.Abort réactivent le thread immédiatement. Dans le cas d'une attente non managée (par exemple, un appel de code non managé à la fonction WaitForSingleObject Win32), ni Thread.Interrupt, ni Thread.Abort ne peuvent prendre le contrôle du thread avant qu'il ne retourne vers ou appelle dans du code managé. Dans du code managé, le comportement est comme suit :
Thread.Interrupt libère un thread de l'attente dans laquelle il peut se trouver et entraîne la levée d'une exception ThreadInterruptedException dans le thread de destination.
Thread.Abort est semblable à Thread.Interrupt, excepté qu'il entraîne la levée d'un ThreadAbortException sur le thread. Pour plus d'informations, consultez Destruction de threads.
Suspension et reprise (obsolète)
.gif "Remarque importante") Remarque importante : |
|---|
Dans le .NET Framework version 2.0, les méthodes Thread.Suspend et Thread.Resume sont marquées obsolètes et seront supprimées dans une version ultérieure. |
Vous pouvez également suspendre un thread en appelant Thread.Suspend. Lorsqu'un thread appelle Thread.Suspend sur lui-même, l'appel bloque jusqu'à ce que le thread soit repris par un autre thread. Lorsqu'un thread appelle Thread.Suspend sur un autre thread, l'appel est un appel sans blocage qui entraîne la suspension de l'autre thread. L'appel à Thread.Resume libère un autre thread de l'état de veille et entraîne la reprise de l'exécution par le thread, quel que soit le nombre d'appels dont Thread.Suspend a fait l'objet. Par exemple, si vous appelez Thread.Suspend cinq fois de suite puis appelez Thread.Resume, le thread reprend son exécution immédiatement à la suite de l'appel à Thread.Resume.
Contrairement à Thread.Sleep, Thread.Suspend n'entraîne pas l'arrêt immédiat de l'exécution par un thread. Le Common Language Runtime doit attendre que le thread atteigne un point sans risque avant de suspendre le thread. Un thread ne peut pas être suspendu s'il n'a pas été démarré ou arrêté. Pour obtenir plus d'informations sur les points sans risque, consultez Thread.Suspend, Garbage Collection et les points sans risque.
| Remarque importante : |
|---|
Les méthodes Thread.Suspend et Thread.Resume ne sont généralement d'aucune utilité pour des applications et ne doivent pas être confondues avec les mécanismes de synchronisation. Comme Thread.Suspend et Thread.Resume ne reposent pas sur la coopération du thread en cours de contrôle, ces deux méthodes sont très peu discrètes et peuvent générer de graves problèmes d'application comme les blocages (par exemple, si vous suspendez un thread qui contient une ressource dont un autre thread aura besoin). |
Certaines applications n'ont pas besoin de contrôler la priorité des threads pour optimiser les performances. Pour ce faire, vous devez utiliser la propriété Priority plutôt que Thread.Suspend.
Voir aussi
Concepts
Vue d'ensemble des primitives de synchronisation
Thread.Suspend, Garbage Collection et les points sans risque