Programmation Concurrente - Séance de TP 3

Un probleme de synchronisation

• Si ce n’est pas deja fait, recuperer ici les classes correspondant au dernier exercice du TP2 : gestion de comptes en banque.
• Pour tester differents scenarios, on vous fournit une autre possibilite (un autre comportement) concernant la classe Client. Quoi qu’il en soit, jouez un peu avec ces differents clients. En utilisant un moniteur, 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. Constater qu’eventuellement l’application ne termine pas : en effet, si le solde d’un compte n’est pas suffisant pour satisfaire toutes les demandes de retrait, alors, les threads de type “Debiteur” restent bloquees.
• Implanter une classe Semaphore, a l’aide d’un moniteur, qui fournit les primitives P() et V()
• Reprendre le probleme de gestion des comptes en banque, cette fois-ci en utilisant un semaphore pour gerer l’exclusion mutuelle des threads devant modifier ou lire le solde. Pour gerer l’attente necessaire si le solde est insuffisant pour effectuer un retrait, utiliser de l’attente (semi-)active
• Essayer d’utiliser aussi un semaphore pour remplacer l’attente active par un endormissement (utiliser un P()). Le reveil d’une thread endormie de type “Debiteur” se fera par un V().
• Reflechir aux problemes poses par une telle approche …sachant qu’il faudrait pouvoir reveiller toutes les threads de type “Debiteur” des qu’un depot d’argent a eu lieu sur le compte (comme nous le faisions grace a un notifyAll()). Or, c’est delicat de savoir precisement et correctement combien de telles threads sont deja endormies dans la file d’attente du semaphore.

Les producteurs / consommateurs

L’objectif de l’exercice est d’implanter le probleme general des producteurs et consommateurs utile dans la simulation du fonnctionnement d’une pizzeria. Et ce de plusieurs manieres…

Recuperer le squelette de l’application Pizzeria

• Utiliser tout d’abord des semaphores pour synchroniser correctement l’acces au Comptoir pour les producteurs et consommateurs. Faites bien attention que les methodes take() et put() qui devront eventuellement se bloquer sur des appels a une primitive P() ne doivent pas etre synchronized. Sinon, l’acces au moniteur risque d’etre impossible pour d’autres threads qui pourraient mettre fin a ces attentes par un V() correspondant.
• Utiliser ensuite un moniteur pour realiser cette meme synchronisation. Faites bien attention que les methodes take() et get() a implanter dans la classe qui represente l’acces synchronise au Comptoir vont endormir dans une meme file d’attente aussi bien des consommateurs que des producteurs.

Travail a rendre (dans le cadre du controle continu)

Avant le lundi 7/03/2011, chaque etudiant doit envoyer un .zip correspondant au travail realise pour l’exercice 2 (pizzeria) version moniteur. Plus precisement, nous attendons une implementation idealement, truffee de commentaires pertinents. Par ailleurs, ce zip devra contenir une solution (papier, cad. en pdf jointe au zip) pour la question 2 de l’exercice 3 du TD2 (oui, c’est bien dans TD2!).