Re: Question whether a problem with race conditions exists in this
case
On 12/16/11 8:27 AM, Lew wrote:
On Thursday, December 15, 2011 6:44:39 AM UTC-8, Tom Anderson wrote:
On Wed, 14 Dec 2011, Saxo wrote:
On Dec 14, 10:26 pm, Eric Sosman<esos...@ieee-dot-org.invalid> wrote:
private Object lock = new Object();
What does `lock' buy you? Why not just synchronize on the
Node itself?
The purpose is only to indicate that some more fine-gtrained locking
would be used for the real thing instead of doing a synchronized(this)
{ ... } thing.
It's quite a common pattern. I'm always a bit dubious about using an
public object (FSVO 'public') as the victim of a synchronized block; how
do i know some random other bit of code in some other thread isn't going
to try to lock the object at some point, and cause trouble? You wouldn't
expose a field, would you? So why expose an object's lock? Essentially, i
see an object's lock as a feature, like a method or a field; it should
only be exposed to other classes after due consideration, and if it is,
its proper use should be documented.
I control that by who sees the object, e.g., a 'Collections.synchronizedList()'.
I see the point in what you're saying but I find it over-cautious sometimes..
It depends on whether you want the object to control its own internal locking,
which sometimes you do, or to be part of its client's thread control, as the numerous standard API classes with 'synchronized' methods do.
I seem to recall this practice of using an internal lock object being
advocated in JCIP, but I'm not near my bookshelf at the moment so I
can't be sure.
I happen to agree with Eric on this one though. If you expose any method
as "synchronized" (whether it is public or not), then you have added an
implicit contract to your object that you may not have intended. That
contract is "If *any* external process synchronizes on this object, it
will be serialized with certain operations I perform."
More often than not, you will want to be explicit about behavior in
concurrent situations, not implicit.
The locking analogue of a private field is an object like the above,
created for the sole purpose of supplying a lock that is provably only
accessible to code which can see the private details of the class.
I have coined the name 'lockguffin' for these objects, and i encourage you
all to use it.
When appropriate.
"When appropriate" should be the default modifier for all statements,
because you shouldn't ever do something when its not appropriate :-)