EVALUATION
From the docs:
* <p>A reentrant write lock intrinsically defines an owner and can
* only be released by the thread that acquired it. In contrast, in
* this implementation, the read lock has no concept of ownership, and
* there is no requirement that the thread releasing a read lock is
* the same as the one that acquired it. However, this property is
* not guaranteed to hold in future implementations of this class.
Therefore, the current behavior is likely intentional.
###@###.### 2004-12-14 06:24:29 GMT
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 submitter can instead use
assert lock.getReadLockCount() > 0;
This is weaker than a per-thread ownership test, but will usually
suffice in practice to catch errors.
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.
###@###.### 2004-12-14 16:17:57 GMT
|