Re: Question whether a problem with race conditions exists in this case
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 th=
e
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.synchronizedLis=
t()'.
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 locki=
ng,
which sometimes you do, or to be part of its client's thread control, as th=
e numerous standard API classes with 'synchronized' methods do.
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 yo=
u
all to use it.
When appropriate.
--
Lew