Pff j arrive pas a dormir, j en profite pour une reponse tardive, mais probablement remplie de fautes d orthographes. Je vais essayer de faire clair..
Sais tu comment fonctionne gcc sur les core duo et les opteron ?
Nope, no idea. Je pense que seul VS2005 (SP1?) et ICC vont mettre une memory barrier, mais a verifier. Un peu d´intrinsic/asm inline ne fait pas de mal 
Que fait il exactement. pourquoi voudrait on faire cela. Quel est le probleme de faire du polling actif sur une variable ?
Ce n´est pas un probleme, mais ce n´est pas recommende, car non optimal. Ok, jvais essayer de faire simple.. Une loop si petite a des effets secondaires sur, par exemple, les procs intel a partir du pentium pro. Les instructions de lecture de de comparaison de cette loop sont passes en "speculative execution", ie le proc va faire du out-of-order execution (pour remplacer ensuite les instructions lue par le proc, ce qu´on appelle les retired instructions). Mais ici il y a challenge sur la memoire (et cache) pour le speculative execution et les instructions normales, donc grosso modo les instructions attendent le resultat de la precedente. Avec l´asm pause, ce n´est plus le cas, et du coup ca libere des resources pour par exemple l´hyperthreading.
Pourquoi ? rdtsc me fournit des informations synchronisé sur les machines ou je l´ai testé (octo optoron, dual core intel, hexa powerPC64)
rdtsc est vraiment qqchose a bannir pour les nouvelles platformes (et meme sur les anciennes). Explication: tout d´abord, l´instruction est prevu pour tournee en ST sur du single core. Rien ne garanti qu´un autre core utilise la meme frequence et possede la meme base de temps (je veux dire par la que si meme les frequences sont les memes, rien ne garanti que le "0" soit le meme). Ensuite, avec le power management, la frequence du processeur peut changer.. QueryPerformanceCounter/Frequency utilise peut etre cette instruction, mais aussi d´autres compteurs hardware. La frequence retourne est (depuis un patch pas si lointain que ca) fixe par core. Par contre, plus couteuses, ses operations sont a effectuer avec moderation si possible, et sur un LP fixe.
C´est super dangereux, ca veut dire que tu t´expose a ce que windows te migre et ce n´est probablement pas ce que tu veux. Une algorithimique inteligente devrait te garantir que tu utilise de facon optimale tes processeurs.
Ben si, je veux que windows me migre si possible. Explication: si tu as de grosses threads (a savoir longue duration et cpu intensive), windows va les repartir correctement sur les differents cores. Si tu as d´autres petites threads, elle vont etre reschedulee la ou il y a de la place, et ce n´est pas une mauvaise idee d´utiliser un core sur lequel tourne une grosse thread qui est en wait de sync avec une autre. Sur le game engine sur lequel je taf, ne pas fixer l affinity mask augmente entre 5% et 10% le total cpu usage.. Peut etre un exemple: dualcore, thread A (grand cpu usage), thread B (grand cpu usage), et thread C (petit cpu usage, par exemple overlapped network thread). Si on force l´affinite a A(1),B(2),C(2), et si A est en spinlock/wait avec B, C ne pourra pas etre reschedulee sur le core 1, ce qui n´est pas du tout avantageux.
Certes un design plus avance pourrait permettre de fixer les affinites, mais cela pose d´autres problemes: premierement, on ne peut pas gerer les affinity des third parties / de l´os (driver son, DX, etc), et windows va rescheduler comme il veut ces thread. Avec de la chance, ca se passe bien, mais ca ne sera pas forcement optimal si une de ces thread a aussi un affinity mask.
Ensuite, sans code un peu plus avance, ca interdit le multiple instances.
De meme, pour modifier proprement l´affinity mask d´une thread pour que cela corresponde a un core, il faut connaitre le bon mask et donc pouvoir determiner la topology du system. Ca se fait, pas triviallement par contre, et le code (rempli d´asm inline) est different sur Intel, AMD, etc
D´un point de vue design, c´est pas super propre non plus. Si la premiere passe de design se fait bien, lorsque tu veut rajouter un systeme qui cree une thread juste sur quadcores, il faut definir exactement comment cela va rentrer la dedans, et modifier si necessaire les affinity mask de partout (et connaitre celles des autres systemes)
Perso je pense que Windows fait un tres bon travail dans son scheduling, et je n´ai jamais eut de soucis.
Pour repondre a tes questions sur le multithreading sur windows:
oui le scheduler de windows est premptif. Par contre, il faut bien comprendre voir que ta thread A ne sera activee uniquement (et des) qu´une fois ce qu´elle attendait est pret, et que le scheduler est au courant. Ie faire un spinlock while(m_bool_fini) dans la thread A est une mauvaise idee, mais il faut plutot utiliser un waitforobject histoire que l´os puisse rescheduler (ou faire un sleep(0) apres avoir modifier le boolean dans l´autre thread).
Petit info complementaire: essayer d´eviter ou de limiter les high pri threads, afin d´eviter ce qu´on appele la priority inversion: imaginons qu´il y ait 3 threads, low, medium and high (pour leur priority). low acquiert un lock, high est alors reveillee et preempt low, high veut le lock, du coup medium est reveille et prempt high, et il faut attendre la fin du time quantum de medium pour que low release le lock.
A combien est le quantum de temps maximale de windows ?
Aucune idee j´ai en tete 10ms, mais c´est peut etre xboite ou ps3, je suis plus sur..
Cette valeure est elle modifiable ?
Pouvons nous changer le scheduler de windows au cas ou il ne nous plairait pas ?
No idea de
/kUfa
