Quelle est l'indépendance des threads dans le même processus?

Question

Maintenant, cela peut être une question très novice, mais je n'ai pas vraiment d'expérience avec la programmation multithread et je n'ai pas entièrement compris comment les threads fonctionnent par rapport aux processus. Quand un processus sur ma machine se bloque, dis qu'il attend des E/S qui ne viennent jamais ou quelque chose de similaire, je peux les tuer et les redémarrer car les autres processus ne sont pas affectés et peuvent, par exemple, toujours faire fonctionner mon terminal. C'est très évident, bien sûr. Je ne suis pas sûr qu'il en soit de même avec les threads à l'intérieur d'un processus: Si l'un d'eux se bloque, les autres ne sont-ils pas affectés? En d'autres termes, puis-je lancer un thread "watchdog" qui supervise les autres threads et, par exemple tuer et recréer des threads suspendus? Par exemple, si j'ai un pool de threads que je ne veux pas être drainé par des interruptions occasionnelles.

Answer 1

Les threads sont indépendants, mais il existe une différence entre un processus et un thread, c'est-à-dire que dans le cas de processus, le système d'exploitation fait plus que le "tuer". Il nettoie aussi après. Si vous commencez à tuer des threads qui semblent être bloqués, vous laisserez probablement les ressources verrouillées et similaires, quelque chose que le système d'exploitation fermerait pour vous si vous faisiez de même pour un processus. Par exemple, si vous ouvrez un fichier pour écrire et que vous commencez à produire des données et que vous l'écrivez dans le fichier, et que ce thread se bloque, pour une raison quelconque, tuer le thread laissera le fichier ouvert, et probablement verrouillé, jusqu'à ce que vous fermez le programme entier. Donc, la vraie réponse à votre question est: Non, vous ne pouvez pas tuer les threads à la dure.Si vous demandez simplement à un thread de se fermer, c'est différent parce que le thread est toujours en contrôle et peut nettoyer et fermer les ressources avant de terminer, mais appeler une fonction API comme "KillThread" ou similaire est mauvais.

Answer 2

Si un thread se bloque, les autres continueront à s'exécuter. Cependant, si le thread suspendu a verrouillé un sémaphore, une section critique ou un autre type d'objet de synchronisation, et qu'un autre thread tente de verrouiller le même objet de synchronisation, vous avez maintenant un interblocage avec deux threads morts.

Il est possible de surveiller d'autres threads à partir d'un thread. En fonction de votre plate-forme, il existe des API utilisables: je vous renvoie à celles-ci car vous n'avez pas indiqué pour quel OS vous écrivez.

Answer 3

Vous n'avez pas mentionné la plate-forme, mais en ce qui me concerne, le noyau NT planifie les threads, pas les processus et les menace de manière indépendante de cette manière. Cela peut ne pas être et n'est pas vrai sur d'autres plateformes (certaines plateformes, comme Windows 3.1, n'utilisent pas le multithreading préemptif et si un thread passe en boucle infinie, tout est affecté).

Answer 4

La réponse simple est oui.

Généralement, bien que le code dans un thread gère lui-même ce capot probable. Le plus souvent, de nombreuses API qui effectuent des opérations susceptibles de se bloquer auront leurs propres fonctionnalités de temporisation.

Sinon, un thread attendra non seulement l'opération qui risque de se bloquer, mais aussi une temporisation. Si la minuterie signale d'abord son fonctionnement, l'opération s'est interrompue. Etant donné que pour un chien de garde utile dans ce scénario, il faudrait une certaine coopération de la part du code dans les autres threads, les threads ayant eux-mêmes réglé les délais d'attente ayant plus de sens qu'un chien de garde.

Answer 5

Les fils sont planifiés indépendamment les uns des autres. Vous pouvez donc arrêter et redémarrer les threads suspendus. Les threads ne s'exécutent pas dans un espace d'adressage séparé, de sorte qu'un thread qui se comporte mal peut toujours écraser la mémoire ou prendre les verrous nécessaires aux autres threads dans le même processus.

Answer 6

Il y a un bon aperçu de certains des pièges de la suppression et de la suspension des threads dans la documentation Java, expliquant pourquoi les méthodes qui le font sont obsolètes. Fondamentalement, si vous pensez être capable de tuer un thread, vous devez être très, très prudent pour le faire fonctionner sans une sorte de corruption. Si un thread est bloqué, c'est probablement à cause d'un bug ... dans ce cas, le tuer entraînera probablement une corruption.

http://java.sun.com/j2se/1.4.2/docs/guide/misc/threadPrimitiveDeprecation.html

Si vous devez être capable de tuer les choses, les processus d'utilisation.