[JAVA] thread etat

Fermé

Jip - 2 janv. 2012 à 22:42
Jip - 3 janv. 2012 à 19:56

Bonjour,

je suis occupé à découvrir les thread en java et je ne comprend pas vraiment l'état RUNNABLE, car d'après ce que j'ai compris un thread n'est dans cet état que lorsque c'est à son tour de s'exécuter et il devrait être BLOCKED si l'ordonnanceur a donné la main à a un autre thread, or si je teste ce code

class Test extends Thread{

	Thread thread;

	Test(String s){
		super(s);
	}

	Test(String s, Thread t){
		super(s);
		thread = t;
	}

	public void run(){
		System.out.println("debrun "+getName()+" = "+getState());
		for(int i = 0; i < 1000; i++){
       		System.out.println("run "+getName()+" = "+getState());
       		if(thread!=null) System.out.println("run dans "+getName()+" -> "+thread.getName()+" = "+thread.getState());
		}
	}

	public static void main(String[] args){
		Test a = new Test("A");
		Test b = new Test("B", a);
		a.start();
		b.start();
	}
}

je me retrouve parfois avec un "run dans B -> A = RUNNABLE"
Si quelqu'un pouvait m'éclairer la dessus :)
Merci !

A voir également:

[JAVA] thread etat
Waptrick java football - Télécharger - Jeux vidéo
Jeux java itel football - Télécharger - Jeux vidéo
Java apk - Télécharger - Langages
Java décompiler - Télécharger - Langages
Java runtime - Télécharger - Langages

1 réponse

Réponse 1 / 1

KX Messages postés 16755 Date d'inscription samedi 31 mai 2008 Statut Modérateur Dernière intervention 12 février 2025 3 020
2 janv. 2012 à 22:50

RUNNABLE c'est quand le thread est en train de s'exécuter, donc à chaque fois que tu as this.getState() tu obtiendras RUNNABLE puisque le fait que tu appelles la méthodes signifie que le thread est en action. En revanche quand tu fais thread.getState tu ne devrais avoir RUNNABLE uniquement si thread==this parce que sinon cela signifierai que les deux threads différents s'exécutent en même temps ce qui n'est pas possible.

Jip
Modifié par Jip le 2/01/2012 à 23:35

Oui, j'avais donc pas compris a l'envers :p
mais lors de l'exécution j'obtiens bien

run A = RUNNABLE 
run A = RUNNABLE 
run B = RUNNABLE 
run dans B -> A = RUNNABLE             <-------------- 
run B = RUNNABLE 
run dans B -> A = RUNNABLE 
run B = RUNNABLE
run dans B -> A = BLOCKED
run B = RUNNABLE

est ce possible que le second thread s'exécute simultanément sur un autre coeur de mon processeur ou la JVM fait abstraction de ça ?

Jip
Modifié par Jip le 3/01/2012 à 06:19

Bon après quelque recherches je suis tombé la dessus
http://www.ukonline.be/programmation/java/tutoriel/concurrence/chapitre1/page3.php
qui nous explique qu'un thread a un état RUNNABLE et un RUNNING qui sont tous deux traduit par RUNNABLE lors de l'appel de getState().
Donc si c'est bien le cas ce n'est plus le fait que j'ai deux trois
"run dans B -> A = RUNNABLE"
qui s'affiche qui me dérange, mais pourquoi j'ai autant de
"run dans B -> A = BLOCKED"
étant donnée que mon thread A n'attend aucune ressource du thread B, je ne vois pas pourquoi il se met "BLOCKED"

KX Messages postés 16755 Date d'inscription samedi 31 mai 2008 Statut Modérateur Dernière intervention 12 février 2025 3 020
3 janv. 2012 à 08:17

Il est BLOCKED parce qu'au moment où tu fais getState, c'est la méthode run() de this que tu appelles, donc c'est this qui qui est RUNNABLE, et donc A est BLOCKED en attendant que this rende la main

Jip
3 janv. 2012 à 08:39

Je suis désolé d'insister mais c'est toujours pas clair :)

Dans ce que tu me dis je comprends que dès qu'un thread a la main, tous les autres sont BLOCKED or dans mon exemple je constate que "parfois" mon thread en attente est toujours RUNNABLE(meme si la proportion de RUNNABLE est très faible)
J'ai d'ailleurs continué à chercher un peu et dans "penser en java" je trouve ceci

Runnable: Cela signifie qu'un thread peut tourner quand le mécanisme de
découpage du temps a des cycles CPU disponibles pour le thread. Ainsi, le
thread pourra ou non tourner, mais il n'y a rien pour l'empêcher de tourner
si le scheduler peut l'organiser; il n'est ni mort ni bloqué.

et dans dans ma class Test il me semble que la seule chose que mon thread A attend c'est que l'ordonnanceur lui rende la main, donc si je me fie à cet extrait il devrait toujours être RUNNABLE puisqu'il ne partage aucune ressource, n'attend pas d'I/O etc...

KX Messages postés 16755 Date d'inscription samedi 31 mai 2008 Statut Modérateur Dernière intervention 12 février 2025 3 020
3 janv. 2012 à 09:18

On efface tout et on recommence, j'ai moi même pu mal comprendre comment ça marchait ;-)

Je me réfère à la documentation de Thread.State :

RUNNABLE
Thread state for a runnable thread. A thread in the runnable state is executing in the Java virtual machine but it may be waiting for other resources from the operating system such as processor.

Effectivement, tous tes threads devraient être RUNNABLE, même s'ils ne sont pas tous en cours d'exécutions par la JVM, mais :

BLOCKED
Thread state for a thread blocked waiting for a monitor lock. A thread in the blocked state is waiting for a monitor lock to enter a synchronized block/method or reenter a synchronized block/method after calling Object.wait.

La méthode System.out.println est synchronisée !
En conséquence, si B est en train de faire son affichage, A est bloquée et ne peut pas le faire en même temps (sinon on aurait des lignes qui se mélangeraient) et inversement B peut-être bloquée si A est en train de faire son affichage au même moment.

Discussions similaires

Téléchargement de la Bible en français

état/province ?

Carte sim free + Activation !

application JAVA sur telephone portable !!!!

Trouver des jeux java pour portable.