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 <d...@cs.oswego.edu
<mailto:d...@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
