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é-schedulés pendant l'appel à la fonction println re-codée dans la classe fournie et un autre thread peut commencer une écriture au milieu de celle d'un autre thread.

Cela ne peut jamais se produire avec la méthode System.out.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 à System.out.println, il ne lâche pas le verrou sur System.out. Aucun autre thread ne peut entrer dans l'appel à System.out.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é-schedulé" n'importe quand, même au milieu de son exécution.

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

Rappel : lorsque plusieurs threads coexistent, 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, utilisation des caches, ...),
... liés aux optimisations du code par le JIT.

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();

		System.out.println(counter.value);
	}
}

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

Exécutez le code sur vos machines !

Pour comprendre le comportement, il faut examiner deux choses : le byte code et 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 1ère
putfield Counter.value   // mettre ce résultat dans le champs value