Shared

[Jonathan M Davis]

On Thursday, May 16, 2019 4:35:52 AM MDT Dominikus Dittes Scherkl via 
Digitalmars-d wrote:
> On Wednesday, 15 May 2019 at 09:33:19 UTC, Jonathan M Davis wrote:
> > On Wednesday, May 15, 2019 12:59:00 AM MDT Dominikus Dittes
> >
> > Scherkl via Digitalmars-d wrote:
> >> No, it can't. Disjunct means: It cannot be called unless all
> >> of the given variables are free (not locked by any other
> >> mutex).
> >
> > So, you're proposing that something in the runtime keeps track
> > of which variables are currently associated with a locked mutex
> > in order to guarantee that no other lock block is able to
> > access any of those variables at the same time? That would
> > probably require adding a global lock used by the runtime when
> > any code enters or exists a lock block. I'd be _very_ surprised
> > if anything like that were deemed acceptable for D.
>
> Ok, that can be a problem. But yes, this is what I suggest.
> But why the resistence? Nobody is forced to use mutexes, and if
> you don't that part of the runtime could (should!) be eliminated
> from the program.

For the locking mechanism you're proposing to work, you basically have to
disallow a lot of stuff that is required for other types of thread
synchronization (e.g. casting away shared is needed), and having a global
lock that's used whenever a mutex is used would be terrible for performance.
In general, we want to avoid global locks, and it seems particularly bad to
have a global mutex that needs to be used just to use a normal mutex.

> > And it still doesn't solve the problem of other references
> > referring to any part of the objects referred to by those
> > variables existing and potentially being used elsewhere. If you
> > had
> >
> > lock(mutex, var1)
> > {
> > }
> >
> > and elsewhere
> >
> > lock(mutex, var2)
> > {
> > }
> >
> > when var1 and var2 were references to the same object
>
> Forbidden. See last post.
>
> > or when var2 referred to a piece of data inside of var1,
>
> This would also be impossible. shared vars are no references.

I discussed this in another post, but you _have_ to be able to have shared
references or shared is basically useless.

> > If you only had one mutex for the entire program, and casting
> > away shared were illegal, then something like this could
> > probably work,
>
> Thank you, but why this restriction? There can be as many mutexes
> as you like. The runtime has only to ensure that any running
> locked block doesn't modify any of the vars in the other running
> locked blocks.

If it's at all possible to access any of the shared data that your lock
blocks protect without using the lock block, then your lock block would not
be enough for the compiler to know that it was safe to remove shared from
the data within the lock block. And without a global mutex that's used to
check that different locks aren't being used for the same variable, then
different mutexes could be used for the same varible, defeating the
protection - and even that is assuming that it's not possible to have any
other references to the same data, which would be too restrictive to be
useful. Having multiple references to the same data is a core concept of
sharing data across threads.

- Jonathan M Davis