On Wed, 30 May 2012 19:29:39 +0100, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
On 5/30/12 10:40 AM, Regan Heath wrote:
On Wed, 30 May 2012 18:16:38 +0100, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
On 5/30/12 9:43 AM, Regan Heath wrote:
On Wed, 30 May 2012 17:00:43 +0100, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
On 5/30/12 5:32 AM, Regan Heath wrote:
On Wed, 30 May 2012 10:21:00 +0100, deadalnix <deadal...@gmail.com>
wrote:
You don't want to synchronize on ANY object. You want to
synchronize
on explicit mutexes.
+1 .. this is the key point/issue.
TDPL's design only allows for entire synchronized classes (not
separate synchronized and unsynchronized methods), which pair mutexes
with the data they protect. This is more restrictive than exposing
mutexes, but in a good way. We use such a library artifact in C++ at
Facebook all the time, to great success.
Can you call pass them to a synchronized statement? i.e.
TDPLStyleSynchClass a = new TDPLStyleSynchClass();
synchronized(a) {
}
Yes. Well I recommend acquiring the text! :o)
... because, if you can, then you're exposing the mutex.
No.
For the purposes of this thread, and the anti-pattern/problem we're
discussing, you are.
No. I explained in my previous post that the synchronized statement does
not expose locks. This is not a matter of opinion.
Well, it seems some people disagree here. You are exposing the ability to
lock and unlock them, which is the cause of more frequent deadlocks (this
assertion comes from the M$ article, my experience with them and it seems
from other peoples experience of them as well). You're not exposing the
mutex primitive in any other way, but that's irrelevant for this
discussion. Now, you and I have probably done enough multi-threaded
programming with mutexes that we no longer fall into this trap easily, but
someone just starting in the world of threading/locking is going to,
repeatedly. If we make it impossible to do it "by default", so they have
to think about when/where to apply the mutex, and make the code doing the
locking more obvious, then I think we'd go a long way to making it much
nicer.
It is the combination of synchronized
classes/methods (implicit locking) and external synchronized statements
(explicit locking) which result in the unexpected, accidental, and hard
to see deadlocks we're talking about here.
You can have deadlocks but with synchronized you can't leak locks or
doubly-unlock them. With free mutexes you have all of the above.
I'm not suggesting using free mutexes. I'm suggesting keeping the mutex
private inside the object. Private in this case means cannot be locked by
external code. Which basically means synchronized() is a no go "by
default". This will avoid all the careless accidental deadlock cases
involving synchronized w/ synchronized classes/methods and make people
actually think about when/where to use their mutexes, instead of just
throwing synchronized all about the place. It is sad, because I really
like the scopedness of synchronized but I think it encourages lazy
programming in this case. Note that I said "by default" above, we can
definitely provide library interfaces, structs, classes, etc to make
synchronized work and if we did it would become a conscious choice the
programmer makes to use them, and that should hopefully (because I cannot
predict the future) mean less accidental deadlocks.
People shouldn't create designs that have synchronized classes
referring to one another naively. Designing with mutexes (explicit or
implicit) will always create the possibility of deadlock, so examples
how that could happen are easy to come across.
True. But in my Example 1
Your example 1 should not compile.
o.. k.. I expected you would get my meaning with the simplified example.
Here you are:
[snip]
Runs and deadlocks immediately.
Sure. As I said, synchronized helps with scoping the locks and unlocks,
but not with deadlocks. You can rewrite the example with two bare
mutexes just as well.
Again, I'm not suggesting using "bare" or "free" mutexes. I'm suggesting
keeping the mutex private, so that it cannot be locked without it being
obvious that that's whats happening. If it were more obvious there would
be less chance of an accidental deadlock, and more chance people would
actually use an idea like an "atomic lock of multiple sync primitives"
(your synchronized with multiple mutexes and lock ordering), where
possible. Sadly even that idea only works when both locks are taken in
the same method/function and only if they can and should be taken at the
same time .. which I think is a fairly rare case.
R
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
