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

[Alex Rønne Petersen]

On 30-05-2012 15:10, Regan Heath wrote:
> On Wed, 30 May 2012 13:43:14 +0100, deadalnix <deadalnix at gmail.com> wrote:
>> Le 30/05/2012 14:32, Regan Heath a écrit :
>>> 1. Prevent locking on any/every object. People would have to create a
>>> separate mutex object for locking. This is a little tedious, but it does
>>> make people think about the scope of the locking (where to put the
>>> mutex, who can see/use it, etc). On the flipside it can make people
>>> re-use a mutex for multiple conceptual critical section areas of code,
>>> which is less than ideal, but at least it's not 'broken'.
>>>
>>
>> It is suboptimal, but correct.
>
> Indeed, and can be made optimal with some fine-tuning/work.
>
>>> 2. Allow locking on any/every object but use a different mutex for
>>> synchronized class/methods. So 'synchronized' on a method call locks a
>>> private mutex object, not the object itself. And synchronized(object)
>>> locks the public mutex object. The downside here is that now every
>>> object potentially has 2 mutex objects/handles internally - a public and
>>> a private one.
>>>
>>
>> It doesn't address most of the drawback cited. Notably the fact that
>> every object have a monitor field, but most of them will not use it.
>
> True, I was just mentioning it as an option that solves the key
> issue/problem - not as the best solution to that problem. I think #1 is
> better.
>
> Ultimately the "problem" that needs solving is the fact that
> synchronized classes/methods use a public mutex and this exposure makes
> deadlocks more likely. I was hoping that by giving some examples in
> code, it would become clearer to the people who don't see what all the
> fuss is about.
>
> Yes, having to manually create a mutex is a pain, and as Andrei has
> mentioned a few times having 2 separate things (one object to lock, one
> mutex) which conceptually should be one thing is worse from an
> understanding/maintenance point of view, however..
>
> 1. If the mutex is intended to lock a single object then we can make the
> following options available:
> a. A Lockable class to derive from.
> b. A Lockable struct to compose with (assuming here that the struct will
> be created/destroyed with the object).
> c. A Lockable!(T) wrapper template/struct/class to wrap objects to be
> locked.
> d. A Lockable interface which classes may implement.
> e. Some sort of compiler magic where it supplies the mutex for
> objects/methods marked with "synchronized" or involved in a
> synchronized(object) statement.
>
> 2. If the scope of the locking is greater than a single object, then a
> separate mutex is required/desired anyway.
>
> 1a. would contain a mutex primitive and lock/tryLock/unlock methods (it
> would implement the interface in 1d)
>
> 1b. would also contain a mutex primitive and alias could be used to
> expose the lock/tryLock/unlock methods (it would implement the interface
> in 1d)
>
> 1c. is actually a technique I have used a lot in C++ where the template
> class is created on the stack of a function/critical section and it
> (optionally) locks on creation (or later when lock() is called) and
> always unlocks on destruction as it leaves scope (by any means). It's a
> very robust pattern, and is similar (the inspiration/or result) of/to
> the synchronized block itself.

In D, you can kind of already do that:

void foo()
{
     mtx.lock();
     scope (exit) mtx.unlock();

     // ...
}

It does involve that one extra scope (exit) line, but I'm of the opinion 
that being explicit about that is a good thing.

>
> 1d. could be a requirement for classes which are to be used in
> synchronized statements i.e.
>
> class A : Lockable
> {
> void lock() {}
> void unlock() {}
> }
>
> A a = new A();
> synchronized(a)
> { // calls a.lock()
> ...
> } // calls a.unlock()
>
> 1e. I leave as a opener to Walter/Andrei/the reader .. I've seen many a
> genius idea pop out of nowhere on this forum.
>
> IMO, the wasted space used by the monitor isn't ideal, but it's not a
> "problem" for the general case. It is a problem for people with limited
> memory environments but that's another topic. Talking about both is only
> clouding the discussional waters so to speak.
>
> R
>


-- 
Alex Rønne Petersen
alex at lycus.org
http://lycus.org