On 10/15/15 4:06 AM, Dmitry Olshansky wrote:
On 13-Oct-2015 21:28, Marco Leise wrote:
Am Tue, 13 Oct 2015 12:52:55 +0000
[snip]
Guys, sorry to break into your wishful thinking, but
synchronized(mutex) {}
already works as you want it to since as long as I can think.
Yes, it takes a parameter, yes it calls lock/unlock on the
mutex. :)
Now how hard would it be to support any object (mutex kind) with
lock/unlock?
AFAIK, the way this works is that mutex makes itself its own monitor
object. So any other mutex-like object can follow this pattern. Or did I
misunderstand the question?
Or do we even need it with scope(exit)?
I personally find the enforcement of the scope guard much better than
having to manually add the lock inside the scope. It gives a clear
delineation of where the lock MUST go (before the scope is entered).
you can simulate synchronized(mutex) {} like:
{
auto _lock = scopeLock(mutex);
}
But this is not nearly as robust. One could add junk before the lock,
and no complaints from the compiler.
I don't really understand all the disdain for synchronized here...
-Steve
