Something needs to happen with shared, and soon.

[Michel Fortin]

On 2012-11-16 15:23:37 +0000, Sean Kelly <sean at invisibleduck.org> said:

> 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:
>> 
>>> 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.
> 
> 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.

Perhaps it's just my style of coding, but when designing a class that 
needs to be shared in C++, I usually use one mutex to protect only a 
couple of variables inside the object. That might mean I have two 
mutexes in one class for two sets of variables if it fits the access 
pattern. I also make the mutex private so that derived classes cannot 
access it. The idea is to strictly control what happens when each mutex 
is locked so that I can make sure I never have two mutexes locked at 
the same time without looking at the whole code base. This is to avoid 
deadlocks, and also it removes the need for recursive mutexes.

I'd like the language to help me enforce this pattern, and what I'm 
proposing goes in that direction.

Regarding setSameMutex, I'd argue that the semantics of having one 
mutex for a whole object isn't great. Mutexes shouldn't protect types, 
they should protect variables. Whether a class needs to protect its 
variables and how it does it is an implementation detail that shouldn't 
be leaked to the outside world. What the outside world should know is 
whether the object is thread-safe or not.

-- 
Michel Fortin
michel.fortin at michelf.ca
http://michelf.ca/