[Thread] Plusieurs threads traités parallèlement sur machine multi-core/processeur ?

Bonjour,

Je travaille actuellement sur la parallelisation d'algorithmes/d'heuristiques très lourds en temps CPU. J'étudie plus particulièrement des méthodes permettant de paralléliser le calcul. Travaillant en Java et sous Linux, je souhaiterais savoir si la JVM (java SE 6) de Sun sous Linux va distribuer les différents threads sur les différents processeurs de la machine ( je developpe sur un quad mais l'objectif est de faire tourner sur un serveur equipé de 16 processeurs). Je n'ai pas vraiment trouvé d'info sur ce sujet, je sais simplement que c'est lié à l'implémentation : je m'etais penché sur le sujet il y a un ou deux ans et il me semble avoir lu que les threads java etaient, sous Windows, interprétés comme des threads natifs contrairement à Linux ou tous les Threads étaient enfermés dans un seul processus natif :/
Si quelqu'un a des infos sur le sujet ou s'il connait une source d'information, je lui en suis d'avance très reconnaissant :D

Bon week end,
Aurélien

Que l'on m'arrête si je me trompe mais pour moi, la JVM et l'implémentation du code n'ont aucun pouvoir sur la manière dont vont être répartis les Threads sur les différents processeurs. C'est le système d'exploitation qui gère ça.

C'est l'implémentation faite de la JVM et non pas de mon code qui va determiner la façon dont vont etre traités les threads java

Moi je dirais que c'est les deux : l'OS et la JVM :)

Salut,

Citation:

---

Envoyé par iohack

Que l'on m'arrête si je me trompe mais pour moi, la JVM et l'implémentation du code n'ont aucun pouvoir sur la manière dont vont être répartis les Threads sur les différents processeurs. C'est le système d'exploitation qui gère ça.

---

C'est à la fois vrai et faux :D

Dans certaines implémentation, la JVM peut gèrer les threads elle-même...



Je m'explique : dans les systèmes Unix il existe un modèle de gestion de thread basé sur des processus lourds. Donc à chaque création de thread un nouveau processus est créé avec tout ce que cela implique (copie de mémoire et des ressources). Il me semble que cela simplifiait l'implémentation de la répartition des threads entre les différents processeurs, mais cela avait toutetois le désavantage de proposer des performances lamentables dans un environnement mono-thread...


Du coup les premières JVMs proposaient 2 gestions des threads :

• La première laissait toutes la gestion des threads au système d'exploitation.
• Alors que dans le second cas c'est la JVM qui "simulait" la gestion des threads avec un processus unique. C'est ce qu'on appelle les "green threads". Etant donné qu'il n'y a qu'un seul processus il est impossible de distribuer les tâches sur différents processeurs, mais par contre cela se révèle plus performant en mono-processeur car cela évite la création de plusieurs processus...

On pouvait utiliser les options -native ou -green de java pour passer de l'un à l'autre, par exemple :

Code:

---

java -native -jar MonJar.jar

---

Toutefois, la plupart des Unixes actuels propose un "vrai" modèle de thread basé sur des processus légers, ce qui rend obsolète les "green threads" de la JVM, mais il peuvent toutefois être utilisés sur certains systèmes "exotiques" qui ne proposeraient pas de gestion de thread...


Enfin, il me semble que lorsqu'il sont utilisé, le terme "green thread" est affiché dans la version de Java :

Code:

---

String version = System.getProperty("java.version");

---

a++

Merci bien pour toutes ces informations, je vais vérifier tout cela et viendrais poster mes résultats ici même