Problème ReentrantReadWriteLock: IllegalMonitorStateException

Bonjour,

J'ai un problème lié à l'usage des ReentrantReadWriteLock. Pourriez-vous m'aider?

Voici mon problème : voulant protéger l'accès multi-thread à un objet en écriture mais pas en lecture (pour des raisons de performances), j'ai utilisé les ReentrantReadWriteLock de Java. J'ai utilisé une implémentation quasi identique à celle de la doc :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

public Map<String,String> getTranslationDictionary(String language){ readLock.lock(); try{ if (translationCache==null) { readLock.unlock(); writeLock.lock(); if (translationCache==null) reloadCache(); readLock.lock(); writeLock.unlock(); } return translationCache.get(language); } finally { readLock.unlock(); } }

---

Lorsque je lance mon application, j'attrape a chaque cette erreur :

Code:

---

1 2 3 4 5 6

java.lang.IllegalMonitorStateException at java.util.concurrent.locks.ReentrantReadWriteLock$Sync.tryReleaseShared(ReentrantReadWriteLock.java:275) at java.util.concurrent.locks.AbstractQueuedSynchronizer.releaseShared(AbstractQueuedSynchronizer.java:1215) at java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.unlock(ReentrantReadWriteLock.java:576) at be.approach.brooklyn.logic.impl.ResourceBundleLogicImpl.getTranslationDictionary(ResourceBundleLogicImpl.java:69)

---

Auriez-vous une idée de ce qui ne tourne pas rond?

Merci d'avance pour votre aide!

Salut,



Je pense qu'il y a une exception qui vient semer la pagaille. Dans la doc le code donné ne gère pas les exceptions : (exception handling is elided for simplicity) :?


En fait je suppose que reloadCache() doit remonter une exception, ce qui fait que tout le traitement qui suit n'est pas exécuté... :arrow: on passe directement dans le finally pour "libérer" le readLock alors qu'on ne l'a pas locké (on est dans le writeLock), ce qui remonte une IllegalMonitorStateException qui "cache" la première exception...

C'est le danger des blocs finally : si une exception y survient cela peut en cacher une autre :?


Perso j'utiliserais deux try/finally :

1. Le premier pour libérer le readLock (comme tu le fais déjà).
2. Le second pour restaurer le readLock après l'utilisation du writeLock, et fermé ce dernier.

Ce qui donnerait :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

public Map<String,String> getTranslationDictionary(String language) { // On pose le lock de lecture readLock.lock(); try { if (translationCache == null) { // On libère le lock de lecture // Pour attendre le lock en écriture readLock.unlock(); writeLock.lock(); try { // On effectue le code avec le lock d'écriture if (translationCache == null) reloadCache(); } finally { // On reprend le lock en lecture // Puis on libère le lock en écriture readLock.lock(); writeLock.unlock(); } } return translationCache.get(language); } finally { // On libère le lock de lecture readLock.unlock(); } }

---

A noter qu'on pourrait reprendre le lock en lecture juste après avoir obtenu celui en écriture :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

public Map<String,String> getTranslationDictionary(String language) { // On pose le lock de lecture readLock.lock(); try { if (translationCache == null) { // On libère le lock de lecture // Pour attendre le lock en écriture // Et reprendre le lock en lecture readLock.unlock(); writeLock.lock(); readLock.lock(); try { // On effectue le code avec le lock d'écriture if (translationCache == null) reloadCache(); } finally { // Puis on libère le lock en écriture writeLock.unlock(); } } return translationCache.get(language); } finally { // On libère le lock de lecture readLock.unlock(); } }

---

a++

a++

Ok, super, tu as tout à fait raison, ma méthode générait une exception.
Je n'avais pas pensé que l'exception du finally masquerait l'exception dans ma méthode! Je vais au moins rajouter un printStackTrace dans un bloc catch.

Pour le readlock par contre ce n'est pas nécessaire de le reprendre juste après celui en écriture : le write lock est bloquant pour les read lock aussi. C'est un des avantages de cette technique.

Mais merci beaucoup, tu viens de me débloquer!

Citation:

---

Envoyé par Asterius

Pour le readlock par contre ce n'est pas nécessaire de le reprendre juste après celui en écriture : le write lock est bloquant pour les read lock aussi. C'est un des avantages de cette technique.

---

Oui je sais, mais de toute manière tu dois reprendre le readLock donc autant le faire le plus tôt possible pour ne pas se retrouver dans un cas où on ne le récupèrerais pas ;)

a++