tytouf

Non pas de problème sur les arch intel, il y ce qu’on appelle un snoop qui s’occupe de garder la cohérence entre les caches. Sur d’autres arch par contre (ARM + DSP par exemple), il faut soit même invalider les caches.

@ fb,

reprenons les cours d’architecture et de système d’exploitation :

On appelle généralement thread ou fil d’exécution, le contexte processeur. À côté il y a ce qu’on appelle un contexte mémoire qui permet d’isoler (au niveau données) les fils d’éxécution les uns des autres. Par exemple sous Linux, un processus c’est un contexte mémoire plus un ou plusieurs fil d’éxécution. Effectivement, lors d’un changement de contexte mémoire, il faut invalider le TLB et les caches. Suivant les processeurs cette opération est plus ou moins explicite et plus ou moins couteuse (sur les derniers ARM par exemple ça coute presque rien car le cache est indexé sur les adresses physiques)

Par exemple, le scheduling de Linux travaille sur les threads, lors d’un changement de thread il vérifie si les espaces mémoires sont les mêmes. Si c’est le cas, Linux n’effectue qu’un changement de contexte processeur, sinon il change les deux contextes.

@ dunlop

sauf quand le nombre de coeurs est supérieur au nombre de threads. Dans ce cas, il est souhaitable de pouvoir découper encore un peu plus son application. C’est là que les techniques de programmation parallèle ou distribuée sont nécessaires. Mais l’homme étant généralement faignant, c’est mieux que ce soit la machine qui s’occupe de ça.

Finalement, ces processeurs multi-coeurs servent pour des applications bien précises qui nécessitent beaucoup de puissances de calculs. Pour une utilisation traditionnelle, on devrait voir des processeurs multi-cores dont les coeurs peuvent être mis en veille. Ainsi l’utilisateur a de la puissance sous le capot sans pour autant consommer trop d’énergie.

effectivement il y a toujours débat entre programmation multi-threadée et évènementielle, chaque méthode étant plus ou moins adaptée (facile à développer) pour telle ou telle tâche. néanmoins pour préciser un peu les choses :
1/ pour chaque méthode, il y a un changement de contexte :
 - pour les threads c’est les registres processeurs dont celui contenant la pile
 - pour l’évenementiel c’est l’évenement et sa continuation
2/ si les threads tournent dans le même espace d’adressage mémoire, il n’y a pas besoin d’invalider les caches. La différence de vitesse entre les deux méthodes est donc moins évidente.
3/ Apache gère plus ou moins toutes les configurations : mono-thread, multi-threadé, multi-processus.

sauf si le système affecte les threads à un autre coeur ou bien que le développeur utilise l’API fournit par le système d’exploitation pour le faire.