4

In ReentrantReadWriteLock documentation it is said:

writer can acquire the read lock, but not vice-versa

If I understand correctly it means that from the same thread you can execute:

//thread1
lock.writeLock().lock()
lock.readLock().lock()
print("this line executes")

This makes sense: if you already locked write no other thread can enter the locked code. But if you locked read, why can't you enter the write block in the same thread if no other thread make read lock? So this doesn't work:

//thread1
lock.readLock().lock()
lock.writeLock().lock()
print("this line doesn't execute")

Why do you have to unlock the read before locking write in the same thread?

awfun
  • 2,316
  • 4
  • 31
  • 52
  • You do not need to acquire *both* read and write locks if you intend to read and write. Simply acquiring write will give you the ability to do this. Similarly, once a read lock has been taken, a write lock cannot be taken until the read lock has been released. – Michael Mar 29 '17 at 16:32
  • @Michael: "You do not need to acquire both read and write locks if you intend to read and write. " That's correct, but there are situation where you want to make a transition from holding a write lock to holding a read lock, and this transition is indeed made in that way that you acquire the read lock while still holding the write lock, and then you release the write lock. – Tillmann Jul 30 '20 at 14:52

2 Answers2

5

ReentrantReadWriteLock doesn't mean that the normal rules locking are not followed.

If a thread acquired a lock for reading purpose, it expects the value of the target data not to change for the duration of the lock. Having otherwise would prevent repeatable-reads. Conceptually, if you let a thread (the same or another) acquire a write lock when a read lock is out, you are breaching that rule.

If a thread acquired a lock for writing, it implicitly has reading rights as well, so acquisition of a read-lock can be granted because it doesn't really breach the contract of the lock (if I can write, I can read) nor the expectations of the lock holder (I locked for writing so I am the only one that can read or write now).

Edd
  • 1,350
  • 11
  • 14
  • 3
    Obtaining a write lock when you already have a read lock does not have to breach any rule. It's called _upgrading_, and some reader/writer libraries allow it. When threads A and B both have read permission, and thread A tries to upgrade, the library should block other threads from acquiring read , and it must block thread A until thread B relinquishes read. The downside is, if thread B tries to upgrade instead, then you get a deadlock. Javadoc for ReadWriteLock explicitly permits implementations to work either way, but the authors of `ReentrantReadWriteLock` chose not to allow upgrading. – Solomon Slow Mar 29 '17 at 17:20
0

I don't actually know the answer, but it may be to help you avoid writing code that can deadlock.

Suppose you have two threads that execute the same code. Both threads have acquired a read lock. Then, both threads attempt to acquire the write lock. Neither thread will be able to proceed until the other thread releases its read lock, but neither thread will release it's read lock while it's waiting to upgrade.

A different implementation could detect the deadlock, and throw exceptions in both threads when it is discovered, but maybe someone thought that would either (A) adversely impact the performance for applications that do not require deadlock detection, or (B) complicate the API too much.

By disallowing you to upgrade a read lock to a write lock, they've made it impossible for you to write a program that deadlocks in that particular way.

Solomon Slow
  • 25,130
  • 5
  • 37
  • 57
  • _"I don't actually know the answer..."_ -- If you don't know the answer, then please don't post an answer. StackOverflow is not a discussion site, and answers should be real answers, not just guesses (wrong, by the way). The whole point to SO is to serve as a repository of good questions and answers ***for future readers***. Solving the OP's problem is secondary, and guesses just pollute the site. – Jim Garrison Mar 29 '17 at 16:58
  • @Jim "(wrong, by the way)", please explain why you think Solomon's guess is wrong. – Tillmann Jul 30 '20 at 14:57