Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-6294770

java.util.concurrent.locks.ReentrantReadWriteLock acquisition order

    XMLWordPrintable

    Details

      Backports

        Description

        This bug is present on both Solaris and Windows, cu env requires fixes for both.

        The javadocs for java.util.concurrent.locks.ReentrantReadWriteLock say
        this about acquisition order when there is a reader currently holding
        the lock (the last sentance in the paragraph on Acquisition Order): In
        either case, if readers are active and a writer enters the lock then no
        subsequent readers will be granted the read lock until after that writer
        has acquired and released the write lock.

        However, my test case doesn't behave this way. What happens with a
        non-fair ReentrantReadWriteLock, is that a thread gets the read lock.
        Then, another thread gets enqueued to acquire the exclusive write lock.
        So far so good. Now if you ask another thread to acquire the read lock,
        it barges in front of the thread waiting for the write lock and acquires
        a read lock.

        According to the javadocs, this shouldn't have happened. The docs say
        that the third thread is supposed to wait until after the write lock has
        acquired and then released its write lock before this newly enqueued
        reader should get to have the lock.
        ###@###.### 2005-07-07 22:38:59 GMT

          Attachments

            Issue Links

              Activity

                People

                Assignee:
                martin Martin Buchholz
                Reporter:
                duke J. Duke (Inactive)
                Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                  Dates

                  Created:
                  Updated:
                  Resolved:
                  Imported:
                  Indexed: