[concurrency-interest] ReentrantReadWriteLock improvements
jbloch at gmail.com
Sun Jul 31 13:30:17 EDT 2005
On 7/28/05, Doug Lea <dl at cs.oswego.edu> wrote:
> The specs for ReentrantReadWriteLock included two different
> errors, that led to confusion and complaints:
> 1. In one sentence it said that nonfair lock order might be
> different than arrival order, but in another, it said that
> readers wouldn't get lock if writers were waiting (which is
> meaningless given the first sentence).
> 2. A statement about readers waiting for writers in fair mode
> contradicted the re-rentrancy requirements. (But the implementation
> stupidly obeyed it anyway.)
> We've fixed (for Mustang) the javadoc/spec to be clearer and
> non-contradictory. And we've improved the implementation
> to not only obey the more sensible spec, but to also support
> a method that we've had several requests and RFEs for:
> public int getReadHoldCount()
> Queries the number of reentrant read holds on this lock by the
> current thread. A reader thread has a hold on a lock for each lock
> action that is not matched by an unlock action.
> * unlock of a readlock not held by current thread always throws error
> (before, it would throw an error only if no thread held readlock).
> * the nonfair implementation includes a (cheap) heuristic that
> probablistically avoids writer starvation without incurring
> the overhead of fair mode. This helps avoid unwanted surprises.
> These improvements come at a small (5-15%) performance cost when
> measured under extreme loads. In realistic applications, there's
> probably no noticeable performance effect, and nicer behavior.
> You can see current drafts of revised specs in the usual place
> And sources etc in their usual places.
> Comments and suggestions would be welcome.
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
More information about the Concurrency-interest