Shared

[Jonathan M Davis]

On Saturday, May 11, 2019 3:51:41 AM MDT Dominikus Dittes Scherkl via 
Digitalmars-d wrote:
> I've followed the AGM a little and think, why not go with the
> "disable access to shared" approach, but instead of allowing it
> to be casted away, introduce a "locked scope" lock { } which need
> to be within a function and allow access to shared variables only
> within such blocks?
> It's still up to the user to ensure that such locked blocks
> encapsulate the semantic blocks which need to be kept together to
> safely modify shared variables, but at least the compiler can
> make sure they are not modified outside locked blocks and that at
> any time only one such block is executed on any thread. And such
> blocks should be scarce so they can be examined carefully like
> trusted and everything build upon is verifiable safe.

All that really would do is add a bit of extra syntax around locking a mutex
and casting away shared. It doesn't really change anything with regards to
what happens. The operations are the same, just wrapped. It's also arguably
worse in that it implies that the compiler is actually making something safe
for you, and it isn't. You're still doing the cast. It's still up to you to
make sure that the concurrency aspects are sorted out correctly. It's just
that what's actually happening is less obvious. I'd argue that we really
don't want anything to just remove shared for us if the compiler can't
actually guarantee that doing so is safe, which it can't do in this case.

Also, mutexes aren't the only concurrency mechanism. You have to deal with
stuff like condition variables and semaphores. And even with mutexes, the
actual code flow may not be as simple as

* lock mutex
* cast away shared
* do stuff as thread-local
* make sure no thread-local references to the data exist
* unlock mutex

That's the basic case and what your suggestion targets, but if your code
flow needs to be even slightly different, it won't work, whereas casting
gives a lot more freedom. It might make sense to add such a helper on top of
casting, but casting is still needed.

Regardless, it's clear that Walter and Andrei want to fully look at the
issue - with concurrency and memory model experts - to make sure that
they're doing the right thing rather than simply doing something now that
might be wrong. It's almost certainly the case that part of whatever we get
will involve disabling reading from and writing to shared objects, and
casting is pretty much going to have to be involved with that, but the
details still need to be worked out, and working out all of those details
(like the memory model) could very well affect what we get in unexpected
ways.

It may ultimately make sense to add helper stuff that hides casts, but we
really need to figure out the details of how shared really works before
looking at adding more user-friendly helpers on top of it.

- Jonathan M Davis