Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
2932 connectés 

  FORUM HardWare.fr
  Programmation

  [Java] multithreading et sleep

 
 


Dernière réponse
Sujet : [Java] multithreading et sleep
LeGreg

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 :
  1. Green threads are the default threads provided by the JDKTM. Native threads are the threads that are provided by the native OS:
  3. Native threads can provide several advantages over the default green threads implementation, depending on your computing situation.
  5. Benefits of using the native threads:
  7. 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.
  9. The native threads implementation can call into C libraries that use Solaris native threads. Such libraries cannot be used with green threads.
  11. 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


Votre réponse
Nom d'utilisateur    Pour poster, vous devez être inscrit sur ce forum .... si ce n'est pas le cas, cliquez ici !
Le ton de votre message                        
                       
Votre réponse
[b][i][u][strike][spoiler][fixed][cpp][url][email][img][*]   
 
   [quote]
 
Options

 
Vous avez perdu votre mot de passe ?


Vue Rapide de la discussion
LeGreg

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 :
  1. Green threads are the default threads provided by the JDKTM. Native threads are the threads that are provided by the native OS:
  3. Native threads can provide several advantages over the default green threads implementation, depending on your computing situation.
  5. Benefits of using the native threads:
  7. 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.
  9. The native threads implementation can call into C libraries that use Solaris native threads. Such libraries cannot be used with green threads.
  11. 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

Bandenabos 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 ...).
LeGreg

BenDk97 a écrit a écrit :

merci pour vos réponses. Pour m'autorépondre (apparemment ce forum n'est pas prompt à la réponse), je dirais qu'effectivement les deux propositions reviennent aux mêmes, et un sleep dans le thread principal ne gene pas le thread fils. En fait la notion pere-fils n'existe pas comme dans la gestion multi-processus, tous les threads sont indépendants.




 
Un sleep sur un processus pere (en programmation unix)
n'endort pas un fils, de ce point de vue la ils sont independants. Je dirais qu'ils sont plus independants que des threads, puisqu'un plantage de processus n'entraine pas la mort
des fils, contrairement a un plantage de threads.
 
A+
LEGREG

merci pour vos réponses. Pour m'autorépondre (apparemment ce forum n'est pas prompt à la réponse), je dirais qu'effectivement les deux propositions reviennent aux mêmes, et un sleep dans le thread principal ne gene pas le thread fils. En fait la notion pere-fils n'existe pas comme dans la gestion multi-processus, tous les threads sont indépendants.
 
Petit exemple pour s'en convaincre (et qui m'a permis de trouver ma réponse)
 

Code :
  1. import java.io.*;
  4. class Test extends Thread
  5. {
  7. public void run()
  8. {
  9.  while(true)
  10.  {
  11.  System.out.println("Hello!" );
  12.  try {Thread.sleep(1000);} catch(InterruptedException e) {}
  13.  }
  14. }
  15. }
  17. public class HelloWorld
  18. {
  19. public static void main(String args[])
  20. {
  22.  Test thread=new Test();
  23.  thread.start();
  25.  while(true)
  26.  {
  27.   System.out.println("..." );
  28.   try{Thread.sleep(5000);} catch(InterruptedException e) {}
  29.  }
  30. }
  32. }
ma vraie question est:
la proposition "un thread qui en crée un autre" est-elle équivalente à "deux threads créés par x." ?
 
merci de me répondre ,c'est urgent.
question: si j'ai un thread principal (le main d'une classe) qui lance un Thread fils, puis-je endormir le thread principal (sleep) sans endormir le fils ? est-ce possible ?

Forum MesDiscussions.Net, Version 2010.2
(c) 2000-2011 Doctissimo

Copyright © 1997-2025 Groupe LDLC (Signaler un contenu illicite / Données personnelles)