Something needs to happen with shared, and soon.

[Sean Kelly]

On Nov 16, 2012, at 5:17 AM, Michel Fortin <michel.fortin at michelf.ca> wrote:

> On 2012-11-15 16:08:35 +0000, Dmitry Olshansky <dmitry.olsh at gmail.com> said:
> 
>> 11/15/2012 8:33 AM, Michel Fortin пишет:
>>> If you want to declare the mutex separately, you could do it by
>>> specifying a variable instead of a type in the variable declaration:
>>>     Mutex m;
>>>     synchronized(m) int i;
>>>     synchronized(i)
>>>     {
>>>         // implicit: m.lock();
>>>         // implicit: scope (exit) m.unlock();
>>>         i++;
>>>     }
>> While the rest of proposal was more or less fine. I don't get why we need escape control of mutex at all - in any case it just opens a possibility to shout yourself in the foot.
> 
> In case you want to protect two variables (or more) with the same mutex. For instance:
> 
> 	Mutex m;
> 	synchronized(m) int next_id;
> 	synchronized(m) Object[int] objects_by_id;
> 
> 	int addObject(Object o)
> 	{
> 		synchronized(next_id, objects_by_id)
> 			return objects_by_id[next_id++] = o;
> 	}
> 
> Here it doesn't make sense and is less efficient to have two mutexes, since every time you need to lock on next_id you'll also want to lock on objects_by_id.
> 
> I'm not sure how you could shoot yourself in the foot with this. You might get worse performance if you reuse the same mutex for too many things, just like you might get better performance if you use it wisely.

This is what setSameMutex was intended for in Druntime.  Except that no one uses it and people have requested that it be removed.  Perhaps that's because the semantics aren't great though.