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

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

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8

More information about the core-libs-dev mailing list