Synchronized classes have no public members

Steven Schveighoffer via Digitalmars-d digitalmars-d at puremagic.com
Thu Oct 15 08:16:59 PDT 2015


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


More information about the Digitalmars-d mailing list