On 2012-11-16 15:23:37 +0000, Sean Kelly <s...@invisibleduck.org> said:
On Nov 16, 2012, at 5:17 AM, Michel Fortin <michel.for...@michelf.ca> wrote:
On 2012-11-15 16:08:35 +0000, Dmitry Olshansky <dmitry.o...@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.for...@michelf.ca
http://michelf.ca/
