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