Volatile et Opérations atomiques

algorithme lock-free et opération atomique

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

Sans exécuter le code, que fait ce programme ?
Vérifier, en exécutant le programme (plusieurs fois), si vous avez vu juste.
Comment doit-on corriger le problème ?
Modifier la classe Bogus en conséquence.
On cherche maintenant a accélérer le code de Bogus en utilisant le mot clé volatile au lieu des blocs synchronized.
Créer une classe BogusVolatile qui n'utilise pas de bloc synchronized.
Comment appelle-t-on les implantations qui n'ont ni blocs synchronized, ni lock ?

On cherche à implanter un compteur thread-safe sous la forme d'une classe Counter et de sa méthode nextInt qui renvoie les valeurs du compteur.

   public class Counter {
     private int counter;
     
     public int nextInt() {
       return counter++;
     }
   }

Expliquer pourquoi le code ci-dessus n'est pas thread-safe ?
Ecrire un main démontrant le problème.
Que se passe t'il si on déclare le champ counter volatile ?
Utiliser la classe AtomicInteger et sa méthode getAndIncrement pour obtenir une implantation thread-safe de la classe Counter.
Que veut dire le terme lock-free pour un algorithme ?
Votre implantation est-elle lock-free ?

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

Expliquer comment fonctionne un générateur pseudo-aléatoire et pourquoi l'implantation ci-dessous n'est pas thread-safe.
Utiliser la classe AtomicLong et la méthode compareAndSet pour obtenir une implantation lock-free du générateur pseudo-aléatoire.
Depuis le jdk 1.8, la classe AtomicLong possède une méthode updateAndGet, comment peut-on l'utiliser ici ? Modifiez votre code en conséquence.
Un des inconvénients des champs "atomiques" est qu'ils alourdissent l'allocation nécessaire pour chaque objet. En effet, pour utiliser un long pour chaque objet générateur, il faut allouer 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 implantation du générateur pseudo-aléatoire qui utilise la classe VarHandle. Un VarHandle 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.