Discussion :

[Asterius]

Bonjour,

Je suppose que c'est un grand classique, mais je ne sais plus exactement comment faire pour synchroniser efficacement mes threads. Bon, ça va peut-être ressembler à une question d'examen, mais si quelqu'un a une solution pour moi, elle est bien venue :-)

Pour faire simple, j'ai une HashMap statique dans une classe, une méthode init() qui réinitialise ma map, et une méthode getMap() qui me retourne son instance. Cette map n'est jamais modifiée a l'extérieur de ma classe.

Mon objectif est triple : interdire que plusieurs Threads ne réinitialisent ma Map en même temps, interdire que des Threads ne lisent ma Map quand elle est en train d'être réinitialisée, mais autoriser plusieurs threads à lire la Map en même temps (pour des raisons de performances, car cette Map est très solicitée et peu souvent réinitialisée).

1. Pas d'accès concurrent sur init() : Rajouter le mot clé synchronized sur ma méthode init() est je pense suffisant pour s'assurer qu'un seul Thread à la fois ne réinitialise la Map.

2. Ajouter synchronized à la méthode getMap() est suffisant pour éviter qu'un thread n'appelle ma map lorsqu'on rentre dans la méthode init(), car une méthode synchronized revient à placer un verrou sur la classe. Ce qui veut dire qu'il n'y a donc qu'une seule des méthodes synchronized qui peut être parcourue à la fois.

3. Mais avoir ajouté synchronized sur le getMap() empêche une lecture concurrente, ce qui ici est nécessaire. D'ou la question : comment autoriser une lecture concurrente, interdire une écriture concurrente, ainsi et surtout qu'interdire tout accès à la Map quand elle se réinitialise?


Merci d'avance!

[baos!]

Regarde du côté de la classe Java java.util.concurrent.locks.ReentrantReadWriteLock

Elle permet d'avoir plusieurs locks en lecture en même temps, mais qu'un seul lock en écriture.

[gifffftane]

Peut être dans ton cas pourrais-tu consulter Implement a relaxed immutability model, utilement complété par Java theory and practice: Managing volatility, car à ce je comprends, le map est souvent lu, et peu fréquemment modifié.

[divxdede]

ConcurrentHashMap

[Asterius]

Merci beaucoup pour vos réponses!

Je trouve le système ReentrantReadWriteLock lock très sympa, je pense que je vais l'utiliser. Sinon, merci aussi pour les lectures, c'est très intéressant!

Par contre, pour le ConcurrentHashMap, je lis dans la doc "there is not any support for locking the entire table in a way that prevents all access". Ca ne convient donc pas du tout, à moins que tu n'aies une réponse de plus d'un mot

[divxdede]

Merci beaucoup pour vos réponses!

Je trouve le système ReentrantReadWriteLock lock très sympa, je pense que je vais l'utiliser. Sinon, merci aussi pour les lectures, c'est très intéressant!

Par contre, pour le ConcurrentHashMap, je lis dans la doc "there is not any support for locking the entire table in a way that prevents all access". Ca ne convient donc pas du tout, à moins que tu n'aies une réponse de plus d'un mot

A partir du moment ou le thread qui écrit n'est pas le même que celui qui lit, il est délicat d'utiliser une Map non synchronisée ou prévue a cet effet.

Pourquoi ? car potentiellement si un thread modifie une valeur, cette valeur peut ne pas être directement recopiée dans la mémoire mais va être stockée dans un registre du processeur. Si un deuxieme thread prends l'éxecution et accéde à la donnée alors il va la lire à partir de la zone mémoire qui n'est pas à jour....

Le mot cléf synchronized en plus de permettre un "mutex", permet de gérer ce flush en forcant la recopie de la variable du registre vers la zone mémoire.

C'est la qu'intervient la classe ConcurrentHashMap qui lors de lectures concurrentes, va d'une façon trés complexe (mais efficace) verifié si la zone mémoire est a jour, si oui, il va acceder a l'élement sans aucun processus d'acquisition de moniteur et dans le cas contraire prendra un verrou pour mettre à jour la mémoire.

Donc effectivement, ConcurrentHashMap est insuffisante en l'état car ne te permet pas de bloquer l'ensemble de la table, mais c'est l'implémentation que j'utiliserais derriere ta barriere construite avec le ReentrantReadWriteLock.