[concurrency-interest] The atomicity of StampedLock lock conversion

Chris Vest mr.chrisvest at gmail.com
Fri Oct 10 10:09:41 EDT 2014

Okay, so I was just reading it wrong. Putting in the word “atomically” as you’ve shown makes it clear.


On 10 Oct 2014, at 15:43, Doug Lea <dl at cs.oswego.edu> wrote:

> On 10/10/2014 06:12 AM, Chris Vest wrote:
>> One might, without further research, come to be ostensibly reasonable conclusion
>> that a read-write lock that offers lock conversion, would be able to convert a
>> write-lock into a read-lock atomically.
> Yes.
>> Reading the documentation for the StampedLock#tryConvertToRead, we’re told that
>> if given a write-lock stamp, the method will first release that write-lock, and
>> /then/ obtain a read-lock, thus leaving a window for someone else to grab the
>> lock ahead of us.
> The word "then" doesn't appear in specs. Perhaps we should clarify
> by adding "atomically" in:
>    /**
>     * If the lock state matches the given stamp, performs one of
> =>
>     * If the lock state matches the given stamp, atomically performs one of
>     * the following actions. If the stamp represents holding a write
>     * lock, releases it and obtains a read lock.  Or, if a read lock,
>     * returns it. Or, if an optimistic read, acquires a read lock and
>     * returns a read stamp only if immediately available. This method
>     * returns zero in all other cases.
> And similarly for the others.
> -Doug
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20141010/a51e55b2/attachment.html>

More information about the Concurrency-interest mailing list