[concurrency-interest] ThreadLocal example bug.

Pete.Soper at Sun.COM Pete.Soper at Sun.COM
Wed Sep 27 15:22:37 EDT 2006


OK, this is now bug id 6475885 and starting "soon" if you google 
"UniqueThreadIdGenerator" the fix should show up too. It might help to 
visit this page in case I screwed it up too:

    
http://blogs.sun.com/microwaves/entry/java_lang_threadlocal_example_class

I have something less than 1440 minutes left to study for the hardest 
math test I'll have ever taken at that point in my life, so it's hard to 
attach much weight to the formatting right now.  The choice of names got 
quite a lot of review way back wen and would require another formal 
review by the community. I won't be in the position to facilitate that 
for a while. But I stashed Josh's msg into the bug comments.

Regards,
Pete

I wrote:

>Oh. I thought the fragment of the class file Tom sent me was the code in 
>question. Dang.
>
>Pete
>
>Jason Mehrens wrote:
>
>  
>
>>Pete,
>>
>>The code you have attached bellow is correct (and what i would expect 
>>to see) however, it is not the code out on the web. From 
>>http://download.java.net/jdk6/docs/api/java/lang/ThreadLocal.html
>>
>>import java.util.concurrent.atomic.AtomicInteger;
>>
>>public class UniqueThreadIdGenerator {
>>
>>     private static final AtomicInteger uniqueId = new AtomicInteger(0);
>>
>>     private static final ThreadLocal < Integer > uniqueNum =
>>         new ThreadLocal < Integer > () {
>>             @Override protected Integer initialValue() {
>>                 return uniqueId.getAndIncrement();
>>         }
>>     };
>>
>>     public static int getCurrentThreadId() {
>>         return uniqueId.get(); // INCORRECT
>>     }
>>} // UniqueThreadIdGenerator
>>
>>
>>Regards,
>>
>>Jason Mehrens
>>
>>
>>    
>>
>>>From: Pete.Soper at Sun.COM
>>>To: Jason Mehrens <jason_mehrens at hotmail.com>
>>>CC: concurrency-interest at cs.oswego.edu
>>>Subject: Re: [concurrency-interest] ThreadLocal example bug.
>>>Date: Wed, 27 Sep 2006 13:20:20 -0400
>>>
>>>Hi Jason,
>>>            For the example code field uniqueId is a "dispenser" of 
>>>the next available id value and that is used once per thread (but is 
>>>visible to all threads) via the overriden initialVlaue method 
>>>invocation that is a side effect of the first invocation of 
>>>uniqueNum.get. The per-thread value is maintained by ThreadLocal code 
>>>that you can't see and it never changes for a given thread. But maybe 
>>>I'm missing something. Do you have a misbehaving test?
>>>
>>>Regards,
>>>Pete
>>>
>>> import java.util.concurrent.atomic.AtomicInteger;
>>>
>>> public class UniqueThreadIdGenerator {
>>>
>>>     private static final ThreadLocal < Integer > uniqueNum =
>>>         new ThreadLocal < Integer > () {
>>>             final AtomicInteger uniqueId = new AtomicInteger(0);
>>>             @Override protected Integer initialValue() {
>>>                 return uniqueId.getAndIncrement();
>>>             }
>>>         };
>>>
>>>     public static int getCurrentThreadId() {
>>>         return uniqueNum.get(); // CORRECT
>>>     }
>>> } // UniqueThreadIdGenerator
>>>
>>>      
>>>
>>
>>    
>>
>
>_______________________________________________
>Concurrency-interest mailing list
>Concurrency-interest at altair.cs.oswego.edu
>http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>  
>



More information about the Concurrency-interest mailing list