[ https://issues.apache.org/jira/browse/CURATOR-621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Zili Chen updated CURATOR-621: ------------------------------ Fix Version/s: 5.5.0 > 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)