ReentrantReadWriteLock improvements

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

ReentrantReadWriteLock improvements

Doug Lea

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.

Additionally,
   * 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
   http://gee.cs.oswego.edu/dl/jsr166/dist/docs/
And sources etc in their usual places.

Comments and suggestions would be welcome.

-Doug




_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: ReentrantReadWriteLock improvements

Joshua Bloch
Doug,

   Looks good.

           Josh

On 7/28/05, Doug Lea <[hidden email]> 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.
>
> Additionally,
>   * 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
>   http://gee.cs.oswego.edu/dl/jsr166/dist/docs/
> And sources etc in their usual places.
>
> Comments and suggestions would be welcome.
>
> -Doug
>
>
>
>
> _______________________________________________
> Concurrency-interest mailing list
> [hidden email]
> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
>

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest