Actually, the issue does not seem to have anything to do with synchronized (although, looking at the code it seems that Synchronized Statements have their own issues), but rather that you cannot create shared objects:

class Class {}                                                                                                                                                                                                                                   
void main() {
    auto b = new shared Class();   // Error: direct access to shared `new shared(Class)` is not allowed, see `core.atomic`
}

This is ridiculous, so you can't create shared objects with new?

Oh, wow. I assumed the problem was with `synchronized` because the problem being with `new shared Class` was just too fundamental to even consider!

This is actually a 2.095 regression.

@RazvanN7 created dlang/dmd pull request #14884 "Fix Issue 23709 - Cannot use synchronized on shared class with -preview=nosharedaccess" fixing this issue:

- Fix Issue 23709 - Cannot use synchronized on shared class with -preview=nosharedaccess

https://github.com/dlang/dmd/pull/14884

This is actually two bugs: creating a shared instance isn't possible with new, but the bug description is still accurate since this doesn't compile:


class Class {}
void main() {
    shared Class c;
    synchronized(c) {}
}

% d.d(4): Error: direct access to shared `c` is not allowed, see `core.atomic`

I submitted a new issue:

https://issues.dlang.org/show_bug.cgi?id=23732

This is not a bug. The compiler rewrites the code to:

auto tmp = c;
_d_monitorenter(tmp);
try {  body } finally { _d_monitorexit(tmp); }

So the reading of c needs to be atomic. Note that the original example (synchronized(new shared Class)) currently compiles because creating a shared instance does not need to be protected by a mutex.

So just write:

import core.atomic;

class Class {}
void main()
{
    shared Class c;
    synchronized(atomicLoad(c)) {}                                                                                   
}

And the code will compile.

Arguably, the compiler could automatically wrap `c` into an `atomicLoad`, however, that's based on the assumption that druntime is available and that the users does not employ a different synchronization mechanism.

I will tentatively close this as INVALID, but please reopen if I am missing something.

If the monitor bit is synchronized does the load of c need to be atomic?

(In reply to mhh from comment #8)
> If the monitor bit is synchronized does the load of c need to be atomic?

Yes, because the pointer to the class could be modified before entering the monitor function.

It doesn't make sense from a usability point of view for the compiler to not rewrite using atomicLoad, especially if it's always going to be needed except for when creating a mutex to pass in. That's clearly not going to be common.