Uploaded image for project: 'Apache Curator'
  1. Apache Curator
  2. CURATOR-621

InterProcessReadWriteLock allows the write lock to be taken when the read one is not released

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Resolved
    • Major
    • Resolution: Fixed
    • 5.1.0
    • 5.5.0
    • None
    • None

    Description

      Hi,

      I have the following piece of code

       

      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. }
      

      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

      05. rwLock.writeLock().acquire();
      

      as expected only one goes through, but as soon the process that went through releases the write lock

      11. rwLock.writeLock().release();
      

      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:

      09. rwLock.readLock().acquire();
      

      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.

       

      Attachments

        Issue Links

          Activity

            People

              kezhuw Kezhu Wang
              alezx alex
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Time Tracking

                  Estimated:
                  Original Estimate - Not Specified
                  Not Specified
                  Remaining:
                  Remaining Estimate - 0h
                  0h
                  Logged:
                  Time Spent - 10m
                  10m