Programmation Concurrente - Séance de TP 2

Incoherence a cause de l’entrelacement de threads concurrentes

• Si ce n’est pas deja fait, recuperer ici les classes correspondant a l’exercice 6 du TP1.
• Dans cet exercice, 4 threads s’executent en concurrence: deux incrementent et deux autres decrementent un entier partage x valant initialement 0. Debrouillez-vous pour mettre au point un scenario tel qu’a la fin de ces 4 threads l’entier x ne vaut pas 0. Plusieurs mecanismes possibles : augmenter la longueur de la boucle, utiliser Thread.sleep(…), utiliser Thread.yield()
• Une fois qu’on a un programme incorrect a cause de l’entrelacement, proposer une maniere simple mais efficace pour le corriger

Exclusion Mutuelle avec l’algorithme de Peterson

• Recuperer ici un squelette d’application qui met en oeuvre 2 threads dont l’algorithme est une boucle comprenant une section de code critique. En effet, ces 2 threads ont besoin de s’executer en exclusion mutuelle sur cette portion de leur code, car elles ont besoin d’utiliser la ressource “sortie standard” de maniere exclusive.
• Tester l’application pour constater la necessite de controler l’entree et la sortie de la zone de code dite critique
• Proposer une implantation de l’algorithme de Peterson (limitee au cas facile de 2 activites concurrentes), dans une classe nommee Peterson. Bien tester que son utilisation (via une instance de Peterson connue des 2 threads) permet de correctement resoudre le probleme d’exclusion mutuelle.

Exclusion Mutuelle avec un moniteur Java

• Remplacer la classe Peterson par une autre classe nommee par exemple MoniSC. Cette classe doit resoudre le probleme de l’exclusion mutuelle en utilisant la notion de moniteur de Java.
• Comment faire pour ne pas avoir a modifier le code de la classe Imprimeur, selon que l’on veut synchroniser les 2 threads en utilisant Peterson ou en utilisant un moniteur ?

Une mini-application de gestion de comptes a la banque

• Recuperer ici un squelette d’application qui permet d’ouvrir plusieurs comptes bancaires. Sur chaque compte, plusieurs clients ont procuration, et peuvent donc deposer ou retirer de l’argent.
• Tester l’application fournie
• Expliquer pourquoi dans l’etat, l’implementation presente un risque d’incoherence des donnees
• Ameliorer l’application pour que ce risque n’existe plus.
• A commencer apres le cours suivant: Amenager l’application de sorte que si un client veut retirer plus d’argent que le solde disponible, alors, le client est mis en attente jusqu’a ce que le solde soit suffisant. Pour cela, on fera plusieurs versions: une utilisant la synchronisation naturelle offerte par la notion de moniteur en Java; puis une seconde dans laquelle vous n’aurez le droit d’utiliser que des semaphores.