Menu
I found that the write lock of the ReentrantReadWriteLock provides an isHeldByCurrentThread() method to check whether the invoking thread holds that lock.
But there is no corresponding isHeldByCurrentThread() method for the read lock. Why not?
226
This lock supports a maximum of 65535 recursive write locks and 65535 read locks.
A read lock allows multiple concurrent readers of some data, but it prevents readers from accessing the data while a writer is in the middle of changing it. That ensures that a reader will never see a partial update (a state where the writer has updated some parts of the data but not all of them.
A ReadWriteLock maintains a pair of associated locks , one for read-only operations and one for writing. The read lock may be held simultaneously by multiple reader threads, so long as there are no writers. The write lock is exclusive.
I think the answer is in the comment of Doug Leas that he gave for this issue: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6207928.
Doug Lea writes:
The current design and behavior are intentional. Read-locks are normally not defined to have a notion of ownership, so ownership cannot be tested. … The JSR166 EG has received a few requests to optionally support per-thread read-hold tracking. Doing this would significantly increase lock overhead, so would need to be governed by an optional construction parameter. We are looking into it.
176
ReentrantReadWriteLock.getReadHoldCount() seems to do the job.
34
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
