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