Ce que vous devez faire
a. Complétez la mise en oeuvre de la classe PseudoRandomLock qui met en oeuvre
l’interface PseudoRandom mais de façon thread-safe. Cette mise en oeuvre doit utiliser
un ReentrantLock pour protéger la section critique.
Remarque : Pour désactiver temporairement un test — par ex., désactiver le test
pour la version PseudoRandomAtomic pendant que vous travaillez sur la première
version ou pour désactiver temporairement les tests avec les threads — il suffit de
mettre l’annotation @Ignore devant @Test.
b. Complétez la mise en oeuvre de la classe PseudoRandomAtomic qui met en oeu-
vre l’interface PseudoRandom, là aussi de façon thread-safe. Par contre, cette mise
en oeuvre ne doit pas utiliser de verrous ; elle doit plutôt utiliser une vari-
able atomique : cf. http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/
atomic/AtomicInteger.html
c. Dans le programme de tests TesterPR, complétez la méthode runVersionAvecThreads
pour que le test s’effectue avec des vrais threads.
Note : N’essayez pas de vérifier que la suite de nombres pseudo-aléatoire générée par
une version parallèle est exactement la même que celle générée par la version séquen-
tielle — ce ne serait pas possible puisque les threads vont s’exécuter dans un ordre
arbitraire. Vérifiez simplement que les ensembles de nombres générés sont les
mêmes — cf. http://www.tutorialspoint.com/java/util/arrays_sort_int.htm
d. Complétez le programme Benchmarks.java pour comparer les performances entre
les versions PseudoRandomLock et PseudoRandomAtomic par rapport à la version
PseudoRandomSeq.
Que constatez-vous?