[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:
>Bill,
>
> 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, owner-javamemorymodel@cs.umd.edu wrote:
>Donnie,
>
> 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 - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:34 EDT