[Thread] Synchroniser tous les éléments d'une map

Bonjour,

Voici le diagramme de classes que j'ai fait avec Visio.
http://img400.imageshack.us/img400/8...eclasseyq5.jpg

J'ecris une méthode de la classe C.

Cette classe C contient une map avec pour clé une String et comme valeur un objet de type D.

La classe D contient un SM et un TM qui sont utilisés par d'autres threads (de type autres que C et D). Des mutex (par synchronized) peuvent etre poses sur SM et TM par ces autres threads.

J'ai besoin de verouiller tous les TM et SM (en meme temps ou les uns apres les autres) de tous les D qui sont dans C dans la methode que je suis en train d'écrire.
Grosso modo, j'aimerai pouvoir faire, lorsque je parcours tous les D de la map, l'equivalent de blocs synchronized (element_de_la_map_de_D) qui puissent s'imbriquer.

Mes contraintes :

• Je n'ai pas le droit de verouiller C ou D (pour des soucis de deadlocks :().
• Je n'ai pas le droit de modifier le diagramme. Mais je peux rajouter des attributs dans les classes ou des nouvelles classes en plus.

J'ai cherché un peu partout sur le net avec Google et dans un livre (Java in a nutshell) mais on ne verouille qu'un seul objet.

Je sais que la conception est tres tres mauvaise (ce n'est pas moi qui l'ai faite :cry: ) mais je suis quand meme bien coincé.

Merci d'avance :)

J'ai pas tout compris, mais dans Collections ya une méthode qui s'appelle synchronizedMap. Je sais pas si c'est ce que tu cherches ou si je suis à côté de la plaque :?

à chaque fois tu ne renvoies pas la map, mais tu la recopies dans un bloc locké dans une autre map (new HashMap<?,?>(taMap)) que tu retournes, et celle-ci peut être utilisée en dehors de tout verrou...

Pour etre plus clair C a une map<String, D>.

Ce n'est pas la map que je voudrais synchroniser mais les elements (le TM et SM de chaque D de la map) qu'elle contient. Le but est de verrouiller, depuis C, tous les TM et SM afin de travailler dessus sans que les autres threads ne puissent les modifier.

Tu ajoutes un boolean locked dans tes TM et SM, au moment où tu as besoin de la map tu mets ce boolean à true dans tous les TM et TS des D de la Map (parcours classique des values). Tu fais en sorte que tes Thread ne puissent plus toucher aux SM et TM si locked est à true.
Le problème persiste si des Thread accèdent déjà aux SM ou TM au moment où tu utilises ta Map, auquel cas il faudrait un autre boolean pour savoir qu'un Thread utilise la resssource, voire un int pour savoir le nombre de Threads l'utilisant, et attendre que cette valeur s'annule pour pouvoir locker depuis C.
:sleep:

Je pensais pas avoir une reponse dans la nuit :D

J'ai pensé a faire ce que tu m'as proposé (un sémaphore, si je ne me trompe pas). Je pense qu'il n'y a pas d'autres solutions.

La nuit porte conseil, si je trouve pas autre chose, je le mettrai en resolu demain 8-)

Merci

Il y a deux approches.

Soit tu laisses l'accès relativement libre aux SM et TM, et alors tu dois mettre en oeuvre, depuis l'extérieur, une sorte de discipline d'accés. Elle peut consister à ce que chaque thread se synchronise sur un même objet. Cet objet lock pourra être fourni par C ou par D. La discipline peut aussi consister à réserver un thread pour les accés concurrents.

Cette première approche, par discipline externe, est un peu l'approche de swing, par exemple ; dans le paquetage java.util.concurrent il y a des choses pour en faciliter la mise en oeuvre. Mais cette approche nécessite que tout le monde veuille bien - ou puisse - respecter la discipline. Je ne sais pas si c'est ton cas.

La deuxième approche est de poser la discipline à l'intérieur de l'objet accédé. Comme ici il y en a deux, il faut placer le service dans un objet qui les encapsule. D'après ton schéma, ce serait D.

Cependant, dans cette approche, il faut que l'encapsulation soit complète. S'il est possible d'accéder à SM ou à TM par d'autres voies que D, ou même de les manipuler sans que D ne le sache, alors il ne sera pas possible de faire une synchronisation correcte.

Quelle approche te semble-t-il la plus jouable ?

La seconde approche me semble plus adaptée. Pour acceder aux TM et SM, on passe par D. Il faudrait que j'implemente un semaphore dans D qui permette de retourner un TM ou SM comme il le faudrait.

Heureusement que ce n'est pas un bug urgent, ca me laissera le temps de bien penser a tout ca.

Merci a tous :king: