8005697: Add StampedLock - JEP 155

Doug Lea dl at cs.oswego.edu
Tue Jan 29 14:33:40 UTC 2013


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
>>
>




More information about the core-libs-dev mailing list