Yes. In *Java Concurrency in Practice* lingo, you need to be able to declare
of any non-final, non-volatile field f that is potentially accessed by
multiple threads that f is @GuardedBy(something), where "something" is
usually "this" for non-static fields, but could be any object, like the
referent of a final field of reference type. @GuardedBy(x) means all
accesses to f are with x's built-in lock held, i.e., inside synchronized (x)
{...} -- or if x is a j.u.c.locks.Lock, then wrapped by a try-finally with
x.lock()/x.unlock().In this case, though, the value of the field incr is changing, so it is not suitable as the argument of @GuardedBy. --tim On Tue, Sep 30, 2008 at 7:06 PM, Rob Heittman <[EMAIL PROTECTED]>wrote: > Using an atomic makes more sense. This class predates my reading of > your book ;-) Although, looking at this again, I'm embarrassed to > admit I'm not sure *why* synchronizing on incr doesn't do anything. > Because I'm reassigning it? > > > Slight problem with newUniqueID(), though. Synchronizing on incr doesn't > do > > anything. How about using AtomicLong and masking out the high bits? >
