C++11 : Le modèle mémoire qui a tout changé

Formateur Python en ligne pour débutants

Apprenez Python facilement sans surcharge théorique. Résolvez des tâches pratiques avec vérification automatique et écrivez du code directement dans le navigateur.

Start Course

Comment une norme a sauvé le C++ du chaos du multithreading

Imaginez : vous écrivez un programme multithread en C++, et il fonctionne parfaitement sur votre ordinateur portable. Vous déployez le code sur un serveur — et il plante. Ou pire encore, il donne des résultats incorrects, mais seulement une fois par mois. Cela vous dit quelque chose ? Avant 2011, c'était la norme. Le C++ n'avait pas de modèle mémoire unique — un ensemble de règles décrivant comment différents threads voient les modifications des données. Chaque compilateur et processeur faisait ce qu'il voulait. Résultat : chaos, courses aux données et malédictions contre le multithreading.

C++11 a tout changé. Il a introduit un modèle mémoire standardisé. Cela semble aride ? Et pourtant. Ce modèle est un véritable fondement pour un multithreading sûr et efficace. Dans cet article, nous allons regarder sous le capot : comment fonctionne le modèle mémoire, que sont les opérations atomiques et les barrières mémoire, et comment cela affecte votre code. Si vous programmez en C++ et souhaitez que vos programmes soient prévisibles, lisez la suite.

Le problème : un monde sans modèle mémoire

Avant C++11, le multithreading en C++ ressemblait au Far West. Vous aviez des threads (via pthreads, l'API Windows ou Boost), mais la norme du langage ne disait rien sur la façon dont ils interagissaient via la mémoire. Le compilateur pouvait réordonner les instructions pour l'optimisation, le processeur pouvait modifier l'ordre des écritures dans le cache. Dans le code monothread, c'est sûr : le résultat ne change pas. Mais en multithread, c'est une catastrophe.

Considérons un exemple très simple :

// Drapeau de préparation et donnéesint data = 0;bool ready = false;

// Thread 1 (producteur)void producer() {    data = 42;          // (1)    ready = true;       // (2)}

// Thread 2 (consommateur)void consumer() {    while (!ready);     // attend le drapeau    std::cout << data; // attend 42}

Intuitivement, on pense : si ready == true, alors data est déjà égal à 42. Mais sans modèle mémoire, le compilateur peut échanger (1) et (2) ! Ou le processeur peut rendre l'écriture de ready visible pour un autre cœur avant l'écriture de data. En conséquence, le consommateur verra ready == true, mais lira data == 0. Un bug impossible à détecter avec un débogueur.

Les programmeurs luttaient contre cela manuellement : en insérant des barrières mémoire (asm volatile), en utilisant des variables volatiles (qui ne résolvent pas le problème), en priant. C++11 a enfin donné des règles claires.

Qu'est-ce que le modèle mémoire C++11 ?

Le modèle mémoire est un ensemble de règles formelles définissant dans quelles conditions un thread est garanti de voir les modifications effectuées par un autre thread. Il répond aux questions :

Quand une écriture dans une variable devient-elle visible pour un autre thread ?
Dans quel ordre les opérations de différents threads peuvent-elles être observées ?
Qu'est-ce qu'une course aux données (data race) et comment l'éviter ?

La nouveauté clé de C++11 — les opérations atomiques (std::atomic<T>) et les six modèles d'ordonnancement mémoire (memory_order). Ils donnent au programmeur le contrôle sur la façon dont le compilateur et le processeur réordonnent les opérations.

Maintenant, voyons comment cela fonctionne sous le capot.

Atomicité et ordre : les deux piliers du modèle

Opérations atomiques

Une opération atomique est une opération qui s'exécute entièrement ou pas du tout. Pour les autres threads, elle est indivisible. Par exemple, la lecture ou l'écriture d'un int sur x86 est généralement atomique (si alignée), mais ++count ne l'est pas (c'est une lecture-modification-écriture). C++11 fournit std::atomic<T>, qui garantit l'atomicité pour les types de base.

#include <atomic>

std::atomic<int> counter(0);

// Incrémentation atomiquevoid increment() {    counter.fetch_add(1); // équivalent à counter++, mais atomique}

Mais l'atomicité n'est que la moitié du travail. L'autre moitié est l'