On 7/11/20 6:15 AM, Arafel wrote:
Because the system don't know if just this lock is enough to protect
this specific access. When you have multiple locks protecting multiple
data, things can become messy.
Yes.
What I really miss is some way of telling the compiler "OK, I know what
I'm doing, I'm already in a critical section, and that all the
synchronization issues have been already managed by me".
You do. It's a cast.
Within this block, shared would implicitly convert to non-shared, and
the other way round, like this (in a more complex setup with a RWlock):
```
setTime(ref SysTime t) shared {
synchronized(myRWMutex.writer) critical_section { // From this
point I can forget about shared
time = t;
}
}
```
This isn't checkable by the compiler.
You could accidentally end up referencing shared things as unshared when
the lock is unlocked. If you remove shared, you need to know and
understand the consequences, and the compiler can't help there, because
the type qualifier has been removed, so it's not aware of which things
are going to become shared after the lock is gone.
-Steve
