Re: Question whether a problem with race conditions exists in this
case
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
--232016332-978396667-1323960279=:21168
Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8BIT
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.
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.
tom
--
And the future is certain, give us time to work it out
--232016332-978396667-1323960279=:21168--