synchronized (this[.classinfo]) in druntime and phobos

[Regan Heath]

On Thu, 31 May 2012 10:49:27 +0100, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> On 5/31/12 2:45 AM, Regan Heath wrote:
>> Ok, how about you tell us what term you want to use for the current
>> state of affairs then, because arguing about this is pointless and I'm
>> happy to use whatever term you deem appropriate (because I couldn't care
>> less what the term is - as long as we all know what is meant, which I
>> believe is the case here).
>
> The idiom is called "scoped locking".

So.. the mutex is "scoped locking"?  Doesn't sound right to me.  I think  
the mutex is "available for locking and unlocking" <- need a word for  
that, which is not "exposed".  How about accessible, available, usable, or  
just plain lockable .. So, the problem here is that the mutex is lockable  
by external code via synchronized() and this means a certain type of  
deadlock is possible.

Moving on..

I think the change mentioned in TDPL to restrict synchronized to  
synchronized classes is a step in the right direction WRT wasted monitor  
space and people freely locking anything.  But, it is exactly the case  
which results in more possible deadlocks (the cause of this thread) AND I  
think it's actually far more likely people will want to use a synchronized  
statement on a class which is not itself synchronized, like for example an  
existing container class.

Given that, restricting synchronized statements to synchronized classes  
seems entirely wrong to me.  In fact, I would say you almost want to stop  
people using synchronized statements on synchronized classes because:
1. If a synchronized class is written correctly it should not be necessary  
in the general case(*)
2. It raises the chances of deadlocks (the cause of this thread).
3. It means that classes in general will be simpler to write (no need to  
worry about synchronization) and also more lightweight for use in  
non-threaded/non-shared cases.  (because we'd provide a template wrapper  
to make them synchronizable)

So, more and more I'm thinking it would be better to provide a  
library/runtime co-operative solution where we have an interface which is  
required for synchronized statements, and a wrapper template to implement  
that interface for any existing non-synchronized class.  Meaning, the  
choice is either to write a synchronized class (rare) or a  
non-synchronized class - knowing it can easily be synchronized if/when  
needed.

The "liquid lock" problem mentioned earlier is an interesting one that I  
have not personally experienced, perhaps because I don't lock anything but  
mutex primitives and I never to re-assign these.

(*) Locking on a larger scope can be achieved by providing a method taking  
a delegate (see earlier thread/replies) and/or exposing lock/unlock for  
those few situations where the delegate method cannot be used.  These are  
the few cases in which this cannot be avoided as the lock/unlock are  
separated by more than a single scope (so synchronized statements don't  
help in these cases either).

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/