[PATCH 1/1] Get rid of synchronization in java.util.logging.LogRecord constructor (original) (raw)

Andrew John Hughes gnu_andrew at member.fsf.org
Fri Mar 13 00:21:12 UTC 2009

2009/3/13 David M. Lloyd <david.lloyd at 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