Dans le cas du task scheduler c'est idem, tu creer autant de thread que de core, et certaines architecture (Playstation par exemple) permette de lancer ton thread sur un SPU unique.
Uh, cela me semble être une erreur. volatile ne fait qu'interdire au compilateur de faire le mariole avec les lecture/ecriture optimisées en registre, aucun mécanisme d'atomicité n'entre en jeu.
Et côté pédagogique, il faut par ailleurs justement marteler que les volatile n'ont rien à voir avec l'atomicité car c'est une croyance ancrée par VC++ qui n'était ainsi pas conforme au standard.
Pour le compilateur de Visual Studio (depuis 2003), le mot clé volatile empêche de re-ordering de la variable ==>
http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx
Je pense qu'il ne parle vraiment que du compilateur Visual Studio ici, les autres comme GCC je ne sais pas trop, il doit exister des options de compilations pour faire de même...
On peut voir à partir de la 24min de la vidéo que le compilateur PowerPC fait un peu n'importe quoi, pourquoi changer l'ordre des instructions de manière aussi brutale ? On dirait plus un bug que de l'optimisation.
Non c'est tout a fait normal, il existe 2 type de re-ordering, celle faite par le compilateur et celle faite par le processeur. Seulement 1% des programmeurs s'en souci car le re-ordering devient dérangeant lors d'une application mutlithread, et le plus souvent, l'utilisation de semarphore et mutex cache le problème au yeux du programmeur, ce qui n'est pas du tout le cas en lock free
Pourquoi ne pas simplement utiliser un
lock ?
Le lock comme le semaphore apporte de la contention et des appels au système qui coute énormément de temps, tu peux avoir un gain de 10% sur un système comme le task scheduler. Il existe une autre petite méthode mais à utiliser avec précaution, c'est le spinlock ( utilisation des atomics oblige )
pas optimal le code de l'exemple (try_pop/try_push): une semantics acquire/release va être suffisant et plus performant. là on a une semantics
memory_order_seq_cst c'est tout à fait superflue
C'est du psedo code, le but ici est de faire comprendre le raisonnement lié au lockfree queue.
Il exite un très bon articile d'un autre lead de Ubisoft Montreal dans le livre Game Programming Gems 8 de Jean-François Dubé qui parle également du meme systeme. " Efficient and Scalable Mutli-Core Programming"
1 |
0 |