[concurrency-interest] RRWL with 'bad' Thread.getId() implementations
dl at cs.oswego.edu
Tue Jun 25 19:03:17 EDT 2013
Most people know that I consider acceding to requests
to support per-thread read counts in JDK6 RRWL to be the
worst decision I've ever made in j.u.c. But still not as
bad as someone's decision not to make Thread.getId() a final
We can and probably should fix this immediately by grabbing
the Thread's "tid" field instead of calling getId. Additionally,
I like Chris's idea of adding a non-overridable method so
that others who face this issue can cope.
The alternative of using a weak ref is not a good option.
The reason we use id's to begin with is that if you store
a Thread ref in a ThreadLocal, even with a weak rewf wrapper,
there several common scenarios where it cannot be GCed.
(Some of you might recall discussions about Ephemerons
motivated by this issue. But these never arrived.)
On the form of the added method:
By analogy to Object.hashCode() (orverridable) vs
System.identityHashCode(Object) (not). maybe the
best place for this method is System.getThreadId(Thread)?
(And beyond all this, please start using StampedLock
instead or RRWL if you can. We designed it to be better
in every way, when it is applicable.)
On 06/25/13 12:50, Chris Dennis wrote:
> Hi All,
> While dealing with a customer issue, I ran in to the possibility of
> breaking a RRWL by feeding in Thread instances with colliding thread-ids.
> Inside RRWL the cachedHoldCounter logic assumes that getId() will return a
> unique identifier for a thread. Do people consider this a bug in RRWL or
> not? (I think it would be agreed that this is also a bug in the
> subclassing of Thread)
More information about the Concurrency-interest