Shared

[Jonathan M Davis]

On Tuesday, May 14, 2019 8:32:45 AM MDT Radu via Digitalmars-d wrote:
> On Monday, 13 May 2019 at 16:20:30 UTC, Jonathan M Davis wrote:
> > On Monday, May 13, 2019 9:52:02 AM MDT Dominikus Dittes Scherkl
> >
> > via Digitalmars-d wrote:
> >> [...]
> >
> > Actually, it doesn't. All you've done is lock a mutex and cast
> > away shared. There is no guarantee that that mutex is always
> > used when that object is accessed. There could easily be
> > another piece of code somewhere that casts away shared without
> > locking anything at the same time. And even if this were the
> > only mechanism for removing shared, you could easily use it
> > with the same object and a completely different mutex in
> > another piece of code, thereby making the mutex useless. The
> > type system has no concept of ownership and no concept of a
> > mutex being associated with any particular object aside from
> > synchronized classes (and those don't even currently require
> > that the mutex always be used). And even if the compiler could
> > check that all uses of a particular variable were locked with a
> > mutex, that still wouldn't be enough, because other references
> > to the same data could exist. So, with the construct you've
> > proposed, there's no way for the compiler to guarantee that no
> > other thread is accessing the data at the same time. All it
> > guarantees is that a mutex has been locked, not that it's
> > actually protecting the data.
> >
> > [...]
>
> I had this idea for some time, not sure I can best articulated
> now, but I think a workable solution for shared is closely linked
> with the dip1000 - scoped pointers.
>
> What I mean is that something like:
>
> void doSharedStuff(scope shared(Foo) foo)
> {
> }
>
> Will be able to safely lock/unlock foo and cast away shared'ness
> in the function's scope.
> The compiler can provide guarantees here that foo will not escape.

Sure, it can guarantee that no reference will escape that function, but all
that's required is that another reference to the same data exist elsewhere,
and another thread could muck with the object while the mutex was locked.
There's no question that helpers could be created which would help users
avoid mistakes when casting when casting away shared, but the compiler can't
actually make the guarantee that casting away shared is thread-safe.

- Jonathan M Davis