[concurrency-interest] RRWL with 'bad' Thread.getId() implementations

Stanimir Simeonoff stanimir at riflexo.com
Tue Jun 25 18:24:23 EDT 2013

On Wed, Jun 26, 2013 at 12:20 AM, Martin Buchholz <martinrb at google.com>wrote:

> On Tue, Jun 25, 2013 at 2:16 PM, Aleksey Shipilev <
> aleksey.shipilev at oracle.com> wrote:
>> On 06/26/2013 01:13 AM, Martin Buchholz wrote:
>> On the serious note, we need to frame this discussion a bit. Do you want
>> the bug against RRWL with the testcase Chris had came up with? (That is,
>> do you agree this is the bug in RRWL?)
> I think I agree this is a small bug in RRWL, but I suspect any attempt to
> cure it would be worse than the disease.

Still, you can use another (new) field, the field can be obtained/set
similar to "parkBlocker" in LockSupport.
No ThreadLocal, no Thread.getId()... just need to push the update in the
Thread class which might be more challenging.
Sometimes I think Thread should have a designated long[] accessible through
Java secrets and index obtainable the same way. Cheaper than ThreadLocals
and guaranteed no leaks, usable by core classes only.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20130626/27478d47/attachment.html>

More information about the Concurrency-interest mailing list