Bandenabos a écrit a écrit :
Non, un sleep sur un thread n'endort pas un thread créé depuis le celui-ci.
Par contre il existe la notion de ThreadGroup qui permet de manipuler une arborescence de Threads.
Concernant la remarque précédente, il est faux de dire que le plantage d'un thread entraine le plantage de ses fils.
Un thread est une unité de traitement indépendante qui fonctionne dans un processus. Le processus est, au sens système du terme, un ensemble de thread fonctionnant dans un contexte qui lui est propre (mémoire ...).
|
je crois que tu n'as rien pige.
On distingue habituellement les processus lourds des processus legers (habituellement appeles threads).
Les processus lourds sont executes dans leur propre espace d'adressage (sur les Processeurs et OS modernes), les threads sont executes dans le meme espace d'adressage et ont juste
un contexte d'execution different.
Pour ce qui est du comportement par rapport aux sleeps, plantages, et appels systemes bloquants, cela depend du systeme, ainsi que de la librairie de threads utilises.
Si le processus est considere comme une seule entite par le systeme, un appel systeme sera bloquant pour tous les threads rattaches a ce processus. Quand je dis threads rattaches a ce processus, je n'inclus pas les processus fils qui sont des processus lourds au sens de l'OS.
C'est pour ca que je distingue le sleep au sens d'Unix
et le sleep au sens de java. Le sleep de la librairie de threads java n'endort pas le processus entier mais seulement le thread.
Par contre les erreurs classiques telles les violations d'acces, si elles sont interceptees par le systeme provoque la mort de tous les threads rattaches au processus !
Par ailleurs dans Java c'est encore plus complique puisqu'une distinction est faite entre les green threads (threads applicatifs) et des native threads (threads systemes): cf extrait de la doc du JDK:
Code :
- Green threads are the default threads provided by the JDKTM. Native threads are the threads that are provided by the native OS:
- Native threads can provide several advantages over the default green threads implementation, depending on your computing situation.
- Benefits of using the native threads:
- If you run JavaTM code in a multi-processor environment, the Solaris kernel can schedule native threads on the parallel processors for increased performance. By contrast, green threads exist only at the user-level and are not mapped to multiple kernel threads by the operating system. Performance enhancement from parallelism cannot be realized using green threads.
- The native threads implementation can call into C libraries that use Solaris native threads. Such libraries cannot be used with green threads.
- When using the native threads, the VM can avoid some inefficient remapping of I/O system calls that are necessary when green threads are used.
|
Quel est ce remapping dont il parle? et bien tout simplement
lorsqu'un appel systeme est fait, celui-ci est bloquant pour tout le processus lorsqu'il s'agit de green threads parce que le processus est une entite indivisible au yeux du systeme. POur eviter que les appels soient bloquants, Java est donc oblige de passer par sa propre librairie d'E/S, qui tient compte de ses threads. Si par contre, tu utilises les threads natifs du systeme (ici Solaris), le systeme reconnait chaque thread comme une entite a part entiere et donc peut eviter de tout bloquer lorsqu'un appel d'entre/sortie est fait.
Si certains points ne sont pas clairs me demander 
.
Par ailleurs je ne reagissais pas sur le point d'utilisation de la librairie java (qui n'est pas discutable: un sleep() sur un thread java n'endort pas le processus entier) mais sur la remarque qui etait faite sur la gestion multiprocessus et la relative independance des threads.
A+
LEGREG
