8005697: Add StampedLock - JEP 155

Chris Hegarty chris.hegarty at oracle.com
Tue Jan 29 13:38:01 UTC 2013


This now beggers the question, should we also include a 'public boolean 
isWriteLocked()' method ?

-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