Concurrence

Problèmes liés à la concurrence

Problème d'affichage

La semaine dernière, en TP :

exercice avec les deux versions de println

Ce que vous avez observé ... (1/2)

Les threads peuvent être dé-schédulés pendant l'appel à la fonction println recodée dans la classe fournie et un thread peut commencer une écriture au milieu de celle d'un autre thread.

Cela ne peut jamais se produire avec la méthode IO.println grâce à un mécanisme de synchronisation.

public void println(String x) {
    ...
    synchronized (this) {
        print(x);
        newLine();
    }
}

Ce que vous avez observé ... (2/2)

public void println(String x) {
    ...
    synchronized (this) {
        print(x);
        newLine();
    }
}

La fonction prend un verrou sur this (c'est-à-dire System.out). Elle le lâche uniquement après avoir affiché toute la chaîne (on expliquera ce mécanisme dans le cours suivant).
Même si le thread peut être dé-schédulé pendant l'appel à IO.println, il ne lâche pas le verrou sur System.out. Aucun autre thread ne peut entrer dans l'appel à IO.println tant que le thread qui détient le verrou n'a pas terminé.

Le scheduler entrelace les threads

L'exemple précédent permet de constater qu'une instruction écrite en Java n'est pas atomique : le thread dans lequel elle s’exécute peut être "dé-schédulé" n'importe quand, même au milieu de son exécution.

Quand la mémoire s'en mêle...

Rappel : quand on a plusieurs threads, ils partagent la même mémoire (le tas).

schéma simplifié de la mémoire avec 2 Threads et un Runnable

... les problèmes sérieux commencent

L'utilisation d'opérations non atomiques, combinées au partage de la mémoire, entraîne un certain nombre de problèmes...

... liés aux accès (lecture ou écriture) entrelacés à la mémoire partagée ;
... liés à l'architecture du processeur (multi-cœurs, niveaux de cache, ...) ;
... mais aussi liés aux optimisations du code (par le JIT, en Java).

Le problème de la non-atomicité des instructions

Un exemple qui paraît simple

public class Counter {
    private int value;

    public void addALot() {
        for (int i = 0; i < 10_000; i++) {
            this.value++;
        }
    }

    public static void main(String[] args) throws InterruptedException {
        var counter = new Counter();

        var thread1 = Thread.ofPlatform().start(counter::addALot);
        var thread2 = Thread.ofPlatform().start(counter::addALot);

        thread1.join();
        thread2.join();

        IO.println(counter.value);
    }
}

Ce code présente une data race : deux threads accèdent à une même zone mémoire (ici, le champ value de l'objet counter).

Exécutez le code sur vos machines !

Pour comprendre le comportement, il faut comprendre deux choses :

Que fait réellement ce code ? On va donc examiner le byte code.
Et comment est gérée la mémoire ?

Le byte code

L'instruction Java extraite du code précédent :

this.value++;

peut se traduire en byte code ainsi :

aload 0                  // mettre this sur la pile (pour l'écriture)
aload 0                  // mettre this sur la pile (pour la lecture)
getfield Counter.value   // stocker la valeur à la place de this
iconst 1                 // stocker la valeur 1 sur la pile
iadd                     // additionner les deux valeurs au sommet de la pile
                         // et mettre le résultat à la place de la 1re
putfield Counter.value   // mettre ce résultat dans le champ value

Ce qui se passe en mémoire...

... quand ce code est exécuté par un seul thread :

schéma simplifié de la mémoire avec 1 Thread et Counter

Ce qui se passe en mémoire...

... quand ce code est exécuté par un seul thread :

Ce qui se passe en mémoire...

... quand ce code est exécuté par un seul thread :

Ce qui se passe en mémoire...

... quand ce code est exécuté par un seul thread :

Ce qui se passe en mémoire...

... quand ce code est exécuté par un seul thread :

Ce qui se passe en mémoire...

... quand ce code est exécuté par un seul thread :