[
https://issues.apache.org/jira/browse/CURATOR-621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zili Chen resolved CURATOR-621.
-------------------------------
Resolution: Fixed
> InterProcessReadWriteLock allows the write lock to be taken when the read one
> is not released
> ---------------------------------------------------------------------------------------------
>
> Key: CURATOR-621
> URL: https://issues.apache.org/jira/browse/CURATOR-621
> Project: Apache Curator
> Issue Type: Bug
> Affects Versions: 5.1.0
> Reporter: alex
> Assignee: Kezhu Wang
> Priority: Major
> Fix For: 5.5.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Hi,
> I have the following piece of code
>
> {code:java}
> 01. rwLock.readLock().acquire();
> 02.
> 03. if (data needs to be refreshed) {
> 04. rwLock.readLock().release(); // releaseing read lock becore acquire
> write one
> 05. rwLock.writeLock().acquire();
> 06. if (data needs to be refreshed) { // check again
> 07. try {
> 08. // refresh data
> 09. rwLock.readLock().acquire();
> 10. } finally {
> 11. rwLock.writeLock().release();
> 12. }
> 13. }
> 14. try {
> 15. // read data
> 16. } finally {
> 17. rwLock.readLock().release();
> 18. }
> 19. }
> {code}
> this is the standard read/write lock syntax described here
> [https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/locks/ReentrantReadWriteLock.html]
> I noticed that when 2 processes run that code, if they both try to execute
> {code:java}
> 05. rwLock.writeLock().acquire();
> {code}
> as expected only one goes through, but as soon the process that went through
> releases the write lock
> {code:java}
> 11. rwLock.writeLock().release();
> {code}
> then the other process is able to acquire it and goes to line 06! Even if the
> first process acquired a read lock just before:
> {code:java}
> 09. rwLock.readLock().acquire();
> {code}
> I tested the same code using 2 threads on the same jvm rather than 2
> processes and behaves the same.
> Then I tested 2 threads using the non distributed ReentrantReadWriteLock
> provided with java, and that one behaves correctly not allowing the second
> thread to lock on the write lock until the first thread releases its read
> lock.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
