utilisation du processeur Dual-core w/unique thread Java en cours d'exécution

Question

Possible en double:
Would a multithreaded Java application exploit a multi-core machine very well?

J'ai un fil Java pur et simple comme celui-ci en cours d'exécution sur ma machine dual-core (Environnement Windows XP 32 bits)

public static void main(String[] strs) { 

    long j = 0; 
    for(long i = 0; i<Long.MAX_VALUE; i++) 
     j++; 

    System.out.println(j); 
    } 

Je m'attendais à ce que je m'en tiens à un seul CP U pour exploiter pleinement le cache haute vitesse (puisque dans la boucle nous continuons à fonctionner avec la variable locale j, une utilisation du processeur serait donc 100% et l'autre serait à peu près inactif. À ma grande surprise, les deux CPU sont utilisés à environ 40% ~ 60% après le démarrage du thread et l'utilisation d'un processeur est légèrement supérieure à l'autre.

Ma question est la suivante: Existe-t-il un mécanisme d'équilibrage de la charge du système d'exploitation qui intervient lorsqu'un déséquilibre a été détecté? Dans mon cas, est-il possible que Windows OS a trouvé qu'un processeur atteint presque 100% et l'autre est presque inactif, donc il replie le thread vers un autre CPU périodiquement?

# EDIT1 J'ai trouvé une explication possible: http://siber.cankaya.edu.tr/ozdogan/OperatingSystems/ceng328/node130.html

Answer 1

Lorsque le système d'exploitation exécute threads, il exécute chaque fil pendant une certaine période de temps (par exemple 10-20ms), enregistre alors l'état du fil, et recherche d'autres sujets courir. Maintenant, malgré ce que vous pourriez penser en regardant le graphique d'utilisation de l'UC, le système d'exploitation fonctionne beaucoup plus de threads que ceux de votre programme. Il existe des threads exécutant des boucles d'interface utilisateur, des threads en attente d'E/S, des threads exécutant des services d'arrière-plan, etc. La plupart des threads passent le plus clair de leur temps à attendre quelque chose.

La raison pour laquelle je parle de cela est d'expliquer que du point de vue de l'OS, la situation est plus complexe que cela pourrait paraître. Il y a tout un tas de threads qui font tout un tas de choses, et le système d'exploitation tente de basculer entre eux. Supposons que vous vouliez implémenter une heuristique que si un thread utilisait son entier quantique la dernière fois, alors le système d'exploitation s'efforcera de le programmer sur le même noyau. L'OS doit suivre et prendre en compte plus d'informations, et le succès de l'optimisation peut dépendre de nombreux facteurs difficiles à prévoir.En outre, l'avantage d'affiniser un thread à un noyau est souvent négligeable dans la pratique, de sorte que les systèmes d'exploitation n'essaient pas de le faire automatiquement. Au lieu de cela, ils exposent une fonctionnalité qui permet au développeur de dire explicitement qu'un thread particulier doit être affinitized à un noyau, puis le système d'exploitation respectera la décision. Cela semble être un compromis raisonnable: si votre thread fonctionne mieux lorsqu'il est affinitized à un noyau, il suffit de demander à l'OS de le faire. Mais, l'OS ne prendra pas la peine d'essayer de le comprendre pour vous.

Answer 2

Comme vous le mentionnez, le système d'exploitation va rebondir autour des fils. Le code natif suivant fait également ce que vous avez décrit.

int main(int argc, char** argv) 
{ 
    while(true); 
    return 0; 
} 

Si vous regardez le processus, il est constamment à 25% (à l'aide d'un quad-core), mais le moniteur de ressources de Windows 7 montre qu'aucun des 4 cœurs est à constante de 100%, même si noyau 0 est à un usage plus élevé que les autres.

Le cpu may share cache entre les cœurs, ce comportement ne signifie donc pas que le cache n'est pas utilisé.

Answer 3

http://en.wikipedia.org/wiki/Preemption_%28computing%29

http://en.wikipedia.org/wiki/Computer_multitasking#Preemptive_multitasking.2Ftime-sharing