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-436664409-1324061400=:13913
Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8BIT
On Fri, 16 Dec 2011, 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()'.
That's why i said "public object (FSVO 'public')" - there are times when
you can wrap your objects like that, but others when it doesn't make
sense, because of the extra complexity it introduces.
Wrapping is definitely a powerful tool here, though, very good point.
Wrapping is, generally, a way of creating a sort of neutral zone; things
that are behind the wrapper can be public without actually being very
exposed. You control their effective scope by controlling the availability
of the reference.
I see the point in what you're saying but I find it over-cautious sometimes.
Fair point. I suppose this is something you can do if you want to be able
to make strong assumptions about when the object is locked. You don't
always need that.
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.
Yes, quite true. This is what i was getting at with "an object's lock
[...] should only be exposed to other classes after due consideration, and
if it is, its proper use should be documented". Making it part of the
client's thread control is a valid thing to do, but it should be a
considered act.
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.
Oh, sorry, i meant that i encourage you to use the name, not the pattern!
The name is always appropriate; the pattern certainly might not be.
tom
--
Get a fucking hobby that isn't breathing, browsing 4chan, or fapping. --
The Well Cultured Anonymous, on Manners
--232016332-436664409-1324061400=:13913--