There's still a race condition between unlocking the monitor and freeing the memory.
Sent from my iPhone On Jan 7, 2012, at 7:25 AM, "Steven Schveighoffer" <[email protected]> wrote: > On Wed, 04 Jan 2012 19:12:04 -0500, Sean Kelly <[email protected]> wrote: > >> On Jan 4, 2012, at 2:55 PM, Andrew Wiley wrote: >> >>> On Wed, Jan 4, 2012 at 2:12 PM, Sean Kelly <[email protected]> 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
