Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
l'ordre d’exécution d'un thread
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
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.Envoyé par Sanguko
Oui et non.
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.
Tu es sur de ca? Ca me parait bizarre, qu'un thread java puisse bloquer tous les thread de la jvm.
Répondre avec citation
Partager