Some Issues With Synchronized

[Steven Schveighoffer]

On Wed, 04 Jan 2012 19:12:04 -0500, Sean Kelly <sean at invisibleduck.org>  
wrote:

> On Jan 4, 2012, at 2:55 PM, Andrew Wiley wrote:
>
>> On Wed, Jan 4, 2012 at 2:12 PM, Sean Kelly <sean at invisibleduck.org>  
>> wrote:
>>>
>>>
>>> This assumes that there is no existing monitor for the object.  At  
>>> best you'll get a memory leak here.
>>
>> Then is there any way to safely use this sort of idiom? Putting it on
>> the first line of the constructor was the earliest way I could see to
>> try to swap the lock.
>
> Not currently.  The relevant ctor for Mutex actually has an  
> "assert(o.__monitor is null)" clause in it that simply never triggers  
> because we ship a "release" build (I hate that label).  The problem is  
> that replacing an existing monitor means a race condition, since other  
> threads might be trying to lock it or are waiting on it at the time.   
> The real issue is that the ctor for a synchronized module shouldn't be  
> synchronized, but I'll grant that it's easier to fix this in  
> user/library code than sort out a compiler fix.  What you can do is:
> ---
> extern (C) void _d_monitordelete(Object h, bool det);
> synchronized class Queue1 {
> private:
>    bool _work;
>    Condition _cond;
> public:
>    this() {
>         _d_monitordelete(this, true);
>         auto lock = new Mutex(this); // initialize the monitor for this  
> object
>        // so we can use the same lock in the Condition
>        lock.lock(); // HACK: acquire the lock so we can unlock it
>        // at the end of the function
>        _cond = new Condition(lock);
>        _work = false;
>    }
>    ...
> }
> ---
> Obviously not ideal since it requires a lot of hackery, but it should  
> work as desired.

Can Mutex do this?

I'm not sure a synchronized class shouldn't be locked in the ctor, it's  
entirely feasible for a synchronized ctor to place its this reference in  
some global location for other threads to try and lock.

But if Mutex can check if there's an existing lock, make sure it's  
unlocked, then replace it with a new one, I think it should be sound, as  
long as you do it in the ctor before exposing the 'this' reference  
somewhere.

-Steve