Version imprimable
salut:)
L'appel de la méthode start() passe le thread à l'état "prêt", ce qui lui permet de démarrer dès que possible (mais pas nécessairement immédiatement). C'est la machine virtuelle JAVA qui décide du moment auquel le thread va s'exécuter. Lorsque le thread démarre, JAVA appelle sa méthode run().
Je veux poser une question un peu bête :D
Si la machine virtuelle JAVA qui décide du moment auquel le thread va s'exécuter, alors sur quels critères cette machine donne lord d’exécution ?
Bonne question.
Perso je soupçonne un odronnanceur et une file d'attente la dessous. De cette manière lorsque ce sserait le tour du thread, celui-ci partirait.
Java utilise la priorité des threads pour les ordonnancer. Mais java n'oblige pas une vm à scheduler les threads d'une maniere specifique. Les priorités sont plus une recommandation pour la vm qu'une obligation.
A priori, les threads de plus forte priorité sont executés en premier.
En général, l'ordonancement dépend de la gestion des threads de la platforme.
Les threads java étant mappés sur les threads natifs.
Il me semble que sous windows, les threads a priorité égale sont en mode round-robin, et sous linux en mode preemptif.
L'idée, c'est qu'il ne faut pas s'appuyer sur l'ordonnance des threads pour fixer le sequencement de l'execution des threads. Il faut des points de synchronisation, soit en utilisant le mot clé synchronized, soit en utilisant les packages java.util.concurrent*
Concernant les priorités, j'ai déjà remarqué que ces dernières ne sont pas gérées de la même façon selon l'OS. Ainsi sous windaube, si je me rappelle bien, les thread de même priorité se voient allouer le même temps chacun. Sur solaris, cela était plus ou moins aléatoire.
Pour en revenir à notre problème, peut-être que la JVM attends une réponse de l'OS, et ce serait cette attente qui bloquerait l'exécution ?
J'espere que ma remarque reste d'actualite: oui il y a bien des Jvm dont la gestion des threads est plus independantes de l'OS: greeen threads.Citation:
Envoyé par Sanguko
Oui et non.Citation:
Envoyé par ndp
En fait les jvms recentes (à partir de la 1.2 je crois) utilisent par defaut les threads natifs.
Il n'empeche qu'une implementation sur les green thread est necessaire si la plateforme n'a pas de threads natifs. Se pose alors le problème des appels bloquant (comme les entrees/sorties), qui bloquent en fait tous les green threads de la vm.
merci pour les precisions.Citation:
Envoyé par Sanguko
Tu es sur de ca? Ca me parait bizarre, qu'un thread java puisse bloquer tous les thread de la jvm.Citation:
Envoyé par Sanguko
Pas tant que çà, les green threads sont des threads software , donc ordonnancés et exécutés par la machine virtuelle.Citation:
Envoyé par ndp
Donc si l'un des threads effectue une action bloquante au niveau de la JVM (les IO on tendances à faire ce genre de choses) il est probable que l'exécution des autres threads se mette en pause)
C'est un des principaux reproches fait aux green threads (avec le fait de ne pas pouvoir exploiter le multi-processeur). Sinok a bien décrit le pourquoi.Citation:
Envoyé par ndp
Pour contourner le probleme, les appels bloquant doivent etre transformer en appels asynchrones. Ce qui augmente la complexité de l'implémentation de la vm, et ajoute un délai par rapport à un appel direct (le temps de recevoir l'événement).
thx