8005697: Add StampedLock - JEP 155

Doug Lea dl at cs.oswego.edu
Tue Jan 29 12:24:11 UTC 2013

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


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.


More information about the core-libs-dev mailing list