shared - no read/write access

[Manu]

On Tue, Apr 2, 2019 at 4:40 AM Kagamin via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> On Sunday, 31 March 2019 at 07:12:08 UTC, Jonathan M Davis wrote:
> > If the compiler can guarantee thread-safety, then there
> > shouldn't be a problem, and nothing needs to be made illegal,
> > but that's usually not the case. The primary exception would be
> > stuff like atomics, and that's typed with shared, so you can
> > pass shared variables to them. And it's not a problem, because
> > thread-safety is guaranteed.
>
> False sense of thread safety already? Code is not magically
> thread safe because it uses atomics, they are only a tool. Thread
> safety is a global property and can't be easily provided on low
> level alone. But added churn can increase mistakes because of
> increased cognitive load.
>
> > In the cases where synchronization _is_ needed, then those
> > operations should be illegal, requiring the programmer to
> > protect the object appropriately and then cast away shared to
> > operate on it while it's protected. That way, nothing marked as
> > shared is violating thread-safety, and the code where there is
> > a risk of violating thread-safety is @system. So, it becomes
> > fairly easy to grep for the portions of the code where you need
> > to worry about threading bugs.
>
> @safe code might be disallowed to access shared data, that's
> understandable, but like for @system, it's difficult to provide
> protection for shared code that can pull its weight.
>
> Also greppability implies that casting away shared is not really
> inevitable, it's needed if you want to apply algorithm that was
> written for thread local data, but keeping data and methods as
> shared will help communicate that it's not an ordinary thing
> happening here (a use case for private shared methods).

I think a lot of people just don't quite visualise what shared means right.

I think it's a fact that `shared` data can not be read/written,
period... not under any circumstance.
If you want to touch it, it's only reasonable to access shared data if
you have confidence that you're the only one accessing it at that
moment. In that sense, it's a reasonable description to say that you
are creating (or asserting) a thread-local context with respect to
that data, and we express that by casting away shared.
It's on you to assure that the thread-local environment you are
assuming is true. The compiler can't help with this.
Taking a mutex is one such form of creating that thread-local context;
if you lock others off from accessing this data, then it is
effectively thread-local to you for that period, so you may cast away
shared and access it during that window.

This code can never be @safe. But it may be tested and @trusted.

Nothing means anything though if you can read/write to shared data as
you can right now. If that's possible, shared has no meaning at all,
and no value that I can figure.