8005697: Add StampedLock - JEP 155

[Chris Hegarty]

Updated javadoc and webrev:

http://cr.openjdk.java.net/~chegar/8005697/ver.01/javadoc/StampedLock.html

http://cr.openjdk.java.net/~chegar/8005697/ver.01/webrev/webrev/

-Chris.

On 01/29/2013 02:33 PM, Doug Lea wrote:
> On 01/29/13 08:38, Chris Hegarty wrote:
>> This now beggers the question, should we also include a 'public boolean
>> isWriteLocked()' method ?
>
> Should and do :-) (Approx line 783)
>
>      /**
>       * Returns true if the lock is currently held exclusively.
>       *
>       * @return true if the lock is currently held exclusively
>       */
>      public boolean isWriteLocked() {
>          return (state & WBIT) != 0L;
>      }
>
>>
>> -Chris.
>>
>> On 01/29/2013 12:24 PM, Doug Lea wrote:
>>> On 01/29/13 03:04, Martin Buchholz wrote:
>>>
>>>> On Mon, Jan 28, 2013 at 4:01 PM, Doug Lea <dl at cs.oswego.edu
>>>> <mailto:dl at cs.oswego.edu>> wrote:
>>>>
>>>>     I also noticed that I had failed to include the simple
>>>>     toString-based informal debug/monitoring aids that we've
>>>>     been doing for synchronizers.
>>>>
>>>>
>>>> Which suggests looking for other missing methods by comparing
>>>> lock-like classes.
>>>> Looking at the implementation of toString and comparing with RRWL
>>>> suggests
>>>
>>>> +
>>>> +    /**
>>>> +     * Queries the number of read locks held for this lock. This
>>>> +     * method is designed for use in monitoring system state, not for
>>>> +     * synchronization control.
>>>> +     * @return the number of read locks held
>>>> +     */
>>>> +    public int getReadLockCount() {
>>>
>>> Yes, thanks. This also falls under the heading of never tempting
>>> people to parse toString() output because they don't see a
>>> corresponding method. I added it, with a few file rearrangements
>>> to keep the status methods all together.
>>>
>>> On 01/29/13 05:57, Chris Hegarty wrote:
>>>>> trivially, the commented assert added with these fixes is missing a
>>>>> trailing ';'.
>>>>>    // assert (s & ABITS) >= RFULL
>>>
>>> Thanks!
>>>
>>> Also: Given all the flag-day discussions, I had used, for now,
>>> ThreadLocalRandom for adaptive spins to avoid dependencies
>>> on the internal-support additions done with TLR update.
>>> But as mentioned with the TLR updates, it is better for
>>> internal components to use the "secondary seed" support
>>> now in updated LockSupport. This avoids all possibility
>>> of disrupting expected user-visible statistical properties
>>> of the public ThreadLocalRandom, without otherwise impacting
>>> performance in either direction.
>>> But since the LockSupport method will be part of this
>>> openjdk commit, I changed to use it now, rather than requiring
>>> a future resync.
>>>
>>> -Doug
>>>
>>
>