Volatile, Atomic, Compare and Set

Exercice 1 - A vos chronometres

On cherche à savoir combien on peut faire d'itération d'une boucle en 100 millisecondes, un de vos collègues a produit le code suivant:

1. Sans exécuter le code, que fait ce programme ?
2. Vérifier en exécutant le programme si vous avez vu juste.
3. Comment doit on corriger le problème ?
   Modifier la classe Bogus en conséquence.
4. On cherche maintenant a accelérer le code de bogus et en utilisant le mot clé volatile au lieu des blocs synchronized.
   Créer une classe BogusVolatile qui n'utilise pas de block synchronized.
   Comment appele t'on les implantations qui n'ont ni block synchronized ni lock ?

Exercice 2 - Au compteur

Finalement votre collègue décide de vérifier ce qui se passe si au lieu d'avoir un compteur en variable locale, le compteur est déclaré comme un champ.

1. Expliquer pourquoi le compteur global n'est pas égal à la somme des deux compteurs locaux ?
2. On souhaite corriger ce comportement pour le moins bizarre. Expliquer comment la classe AtomicLong permet de résoudre le problème.

Exercice 3 - Generateur pseudo-aléatoire lock-free

On souhaite modifier la classe RandomNumberGenerator pour la rendre thread-safe sans utiliser ni section critique ni verrou (lock free donc).

1. Expliquer comment fonctionne un générateur pseudo-aléatoire et pourquoi l'implantation ci-dessus n'est pas thread-safe.
2. Utiliser la classe AtomicLong et la méthode compareAndSet pour obtenir une implantation lock-free du générateur pseudo aléatoire.
3. Un des inconvénients des champs "atomiques" est qu'ils allourdissent l'allocation nécessaire pour chaque objet. En effet, pour utiliser un long pour chaque objet générateur, il faut alloouer pour chacun des objets un AtomicLong qui permettra lui-même d'accéder de manière atomique à la valeur d'un long, chaque accès nécessitant lui-même une indirection...
   Faites une nouvelle implémentation du générateur pseudo aléatoire qui utilise un AtomicLongFieldUpdater de la classe AtomicLongFieldUpdater qui ne nécessite qu'une seule instance (static) pour mettre à jour de manière atomique le champ volatile long de n'importe lequel des objets générateur de cette classe.
4. Depuis le jdk 1.8, vos deux classes précédentes peuvent utiliser la méthode updateAndGet sur AtomicLong comme sur AtomicLongFieldUpdater. Modifiez votre code en conséquence.