2009/3/13 David M. Lloyd <david.ll...@redhat.com>: > On 03/12/2009 07:13 PM, Andrew John Hughes wrote: >> >> This is actually an interesting rare case where two atomic variables >> can replace a synchronised block. Looking at the code, there seems to >> be no issue with the thread being descheduled and then resumed during >> the operation of this constructor. Both atomic variables are only >> used within the constructor. The global sequence number is >> incremented and retrieve atomically and then assigned to a local >> variable. The rest of the code deals with allocating an ID to the >> thread creating the LogRequest object and doesn't depend on the global >> sequence number, so it doesn't matter if this is incremented by >> another thread before the constructor completes. Note that >> Thread.currentThread.getId() now provides an identifier for threads as >> well, but this will reuse the identifiers of dead threads and could >> thus lead to possible confusion between log messages. > > Yeah, while I did find that having a separate global notion of thread IDs > (that starts with 10 no less) was odd, I didn't want to change behavior and > I could not think of a reason to do so, so I retained that notion. > > - DML >
I agree. I also noticed that Thread uses a synchronised block to do the increment rather than the atomic. I don't know if there'd be any advantage to changing it or whether there is a good reason it was done like that. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
