Some Issues With Synchronized
Sean Kelly
sean at invisibleduck.org
Sat Jan 7 08:08:51 PST 2012
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" <schveiguy at yahoo.com> wrote:
> 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
More information about the Digitalmars-d
mailing list