JavaMemoryModel: Email from Josh on extending thread functionality

From: Bill Pugh (
Date: Thu Aug 23 2001 - 12:41:00 EDT

[Josh - I changed your subscription from Joshua.Bloch@eng.Sun.COM to
Joshua.Bloch@Sun.COM so your submissions shouldn't bounce any more].

At 2:17 PM -0400 8/22/01, Joshua Bloch <Joshua.Bloch@Sun.COM> wrote:
> I agree that this functionality (roughly) is desirable. It's something
>that we've known that we needed for years. More generally, the state-space
>defining a thread's existence should be better specified, and accessors should
>be provided to find out what state a thread is in. I do not think that this
>should be done under JSR 133 -- either the maintenance process or a separate
>JSR would be more appropriate.
> Josh

At 2:31 PM -0400 8/22/01, wrote:
> I do not think that this functionality is necessary or desirable. Joe is
>correct that each thread Object *is* its own identity, and can be used as a
>key in an IdentityHashMap. If you want to associate a unique small integer
>with each thread, you can easily do it with ThreadLocal. In fact, this
>example is in the 1.4 ThreadLocal javadoc:
> public class SerialNum {
> // The next serial number to be assigned
> private static int nextSerialNum = 0;
> private static ThreadLocal serialNum = new ThreadLocal() {
> protected synchronized Object initialValue() {
> return new Integer(nextSerialNum++);
> }
> };
> public static int get() {
> return ((Integer) (serialNum.get())).intValue();
> }
> }
>These numbers aren't *guaranteed* unique, as it is theoretically possible (if
>you have more than 2^32 threads) that the counter wraps. If you're concerned
>about this, you could switch to 64 bit IDs or (God help you) use weak refs to
>keep track of which IDs are still in use.
> Regards,
> Josh
JavaMemoryModel mailing list -

This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:34 EDT