Discussion :

[Mister_Kp]

Bonjour,

J'ai quelques questions concernant les verrou en Java. Plus particulièrement les ReentrantReadWriteLock.

En gros, je peux avoir 2 verrou: un en écriture et un en lecture. Sachant que je peux avoir plusieurs clients qui accèdent en lecture mais un et un seul qui accède en écriture ?

Autre question: est-ce que tous les objets situés entre le:
verrou.lock() et le verrou.unlock() sont protégés ? C'est à dire:

Si j'ai

Code :

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

1
2
3
4
 
verrouLecture.lock();
this.read();
verrouLecture.unlock();

et

Code :

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

1
2
3
4
 
private void read(){
 objetB.contenu();
}

Je suis garanti que mon objetB ne sera pas modifié ?

Dernière question:
Dans le cadre d'une utilisation en réseau (avec des RMI), quels sont les verrous qu'il faut mieux utiliser sachant que je n'aurais pas plus de 4 clients connectés, mais que je dois retranscrire les mouvements de souris de chacun sur l'écran des autres? (au niveau de la latence)

merci à ceux qui m'éclaireront

[adiGuba]

Salut,

En gros, je peux avoir 2 verrou: un en écriture et un en lecture. Sachant que je peux avoir plusieurs clients qui accèdent en lecture mais un et un seul qui accède en écriture ?

Oui c'est exactement ça et c'est la grosse différence avec le synchronized() simple. Dans une application multithreadé si plusieurs threads accèdent aux mêmes données sans les modifier il n'y a aucun problème. Si un seul thread modifie ces données on peut se retrouver dans un état incohérent.

synchronized() limite l'accès à une zone à un seul thread, là ou les ReentrantReadWriteLock autorise plusieurs threads de lecture si aucun thread n'est en écriture...

Autre question: est-ce que tous les objets situés entre le:
verrou.lock() et le verrou.unlock() sont protégés ? C'est à dire:

Si j'ai

Code :

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

1
2
3
4
 
verrouLecture.lock();
this.read();
verrouLecture.unlock();

et

Code :

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

1
2
3
4
 
private void read(){
 objetB.contenu();
}

Je suis garanti que mon objetB ne sera pas modifié ?

Déjà une remarque importante : il faut utiliser un try/finally pour sécuriser le code :

Code :

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

1
2
3
4
5
6
7
 
verrouLecture.lock();
try {
    this.read();
} finally {
    verrouLecture.unlock();
}

Comme ca à la fin du bloc tu libèreras bien le verrou, même si la méthode read() remonte une exception
Cela permet de ne pas laisser un verrou bloqué par erreur...


Sinon, pour revenir à ta question, les verrous ne garantissent pas ton code !!!
Les verrous standard (ReentrantLock et les bloc synchronized) garantissent qu'un seul thread à la fois puisse rentrer dans le bloc correspondant.

Pour les ReentrantReadWriteLock il y a deux modes distincts :

• Les read-lock permettent plusieurs threads d'entrer dans les bloc, à condition que le write-lock ne soit pas utilisé.
• Le write-lock empêche tous les autres threads d'obtenir le lock, que ce soit en lecture ou en ecriture.

Donc c'est à toi de t'assurer que :

• Les lectures se font seulement dans un read-lock (ou un write-lock : celui qui peut le plus peu le moins )
• Les écritures se font dans un write-lock.

En sachant que tu peux acquérir plusieurs fois le même lock sans problème (la seule chose à éviter est d'essayer d'obtenir le write-lock lorsqu'on a déjà le readlock).

Dans le cadre d'une utilisation en réseau (avec des RMI), quels sont les verrous qu'il faut mieux utiliser sachant que je n'aurais pas plus de 4 clients connectés, mais que je dois retranscrire les mouvements de souris de chacun sur l'écran des autres? (au niveau de la latence)

Avec 4 clients la différence avec un bloc sychronized ne doit pas se faire sentir, mais je pense que les readwritelock sont mieux adapté...

Sinon jettes un coup d'oeil au package java.util.concurrent, qui propose un certain nombre de collections qui gèrent les aspects concurrentielles, et qui pourraient très bien répondre à tes besoins...


a++

[tchize_]

Autre question: est-ce que tous les objets situés entre le:
verrou.lock() et le verrou.unlock() sont protégés ?

nan nan nan nan nan, c'est pas magique! C'est un outil qui sert à une méthodologie. Une fois que tu as fait verrou.lock(), la seule garantie que tu as, c'est que personne d'autre ne saura faire de verrou.lock() (si verrou est un verrou exclusif) tant que tu n'aura pas fait de verrou.unlock(). Ce qu'on appelle une ressource "protégée", c'est une ressource qui ne peut être accessible *que* dans le cadre d'un lock, mais c'est à toi de faire çà proprement dans ton code. Si t'oublie de faire un lock quelque part, tu casse ton principe

Dans le cadre du readwrite lock, tant que tout le monde n'a pas libéré les readLock(), personne ne peut faire de writeLock(). De même tant que le writeLock() n'est pas libéré, on ne peut pas faire le readLock().


Pour ton projet RMI, un verrou simple devrait etre suffisant, après tout y a que 4 Thread en concurrence. Par contre, faut bien faire gaffe à ne garder les verrous que le moins de temps possible, comme toujours.