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

[David M. Lloyd]

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