Discussion :

[Asterius]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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!

[adiGuba]

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é... 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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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++

[Asterius]

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!

[adiGuba]

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++