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

David M. Lloyd david.lloyd at redhat.com
Fri Mar 13 00:16:48 UTC 2009

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.

More information about the core-libs-dev mailing list