[concurrency-interest] ThreadLocal example bug.

Joshua Bloch josh at bloch.us
Wed Sep 27 14:59:57 EDT 2006


I would argue that the variable names could be better (and used to be).
Also the vertical spacing conventions and comment conventions aren't exactly
standard (though not far off).  How about this?

import java.util.concurrent.atomic.AtomicInteger;

 public class ThreadId {
     // Atomic integer containing the next thread ID to be assigned
     private static final AtomicInteger nextId = new AtomicInteger(0);

     // Thread local variable containing each thread's ID
     private static final ThreadLocal < Integer > threadId =
         new ThreadLocal<Integer>() {
             @Override protected Integer initialValue() {
                 return nextId.getAndIncrement();
         }
     };

     // Returns the current thread's unique ID, assigning it if necessary
     public static int get() {
         return threadId.get();
     }
 }

Note that the client now says ThreadId.get(), rather than
ThreadIdGenerator.getCurrentThreadId().

           Josh




On 9/27/06, Pete.Soper at sun.com <Pete.Soper at sun.com> 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();
> >      }
> > } // 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();
> >>      }
> >>  } // UniqueThreadIdGenerator
> >>
> >
> >
> >
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20060927/9f685110/attachment.html 


More information about the Concurrency-interest mailing list