Shared - Another Thread

[Manu]

On Fri, Oct 19, 2018 at 6:45 AM Dominikus Dittes Scherkl via
Digitalmars-d <digitalmars-d at puremagic.com> wrote:
>
> On Thursday, 18 October 2018 at 16:24:39 UTC, Manu wrote:
> > On Wednesday, 17 October 2018 at 22:56:26 UTC, H. S. Teoh wrote:
> >> What cracks me up with Manu's proposal is that it is its
> >> simplicity and lack of ambition that is criticized the most.
> >> shared is a clusterfuck, according to what I gathered from the
> >> forum, I never had yet to use it in my code. Manu's idea makes
> >> it a little less of a clusterfuck, and people attack the idea
> >> because it doesn't solve all and everything that's wrong with
> >> shared. Funny.
> >>
> >
> > Elaborate on this... It's clearly over-ambitious if anything.
> > What issues am I failing to address?
>
> First of all, you called it "shared", but what your concept
> describes is "theadsave".
> If you had called it the later, it would have been clear to
> everybody that thread local data is indeed automatically
> threadsave, because only one thread has access to it (that
> "implicit conversion"). But if something is "shared" (in the
> common-world sense), it is of course no more "threadsave" - you
> have to implement special methods to treat it.
>
> Conflating "shared" and "threadsave" in that manner was, I think,
> the biggest mistake of your proposal.
>
> Another point is the part of "how can the compiler support the
> expert in writing threadsave methods" - which you answered with
> "not a little bit at the moment, but we may improve this in the
> future" - and that is not at all satisfying.

I think you've misunderstood.
My proposal is @safe... if you stay @safe, you will receive guarantee
that your code is threadsafe.
If you want to implement a low-level device, you must implement a
@trusted function, and I don't know what the compiler can do to help
you.
You will have to produce unsafe casts, so at least it will be
completely clear every operation you perform that is unsafe.
Users of your @trusted library though will experience @safe code
upward through the stack.

So saying that my response that "there is @trusted code at the bottom
of the stack" is not satisfying is really just a comment on your
opinion about @trusted code in general.

My proposal is designed to be useful and @safe for *users* as primary
goal. Authors that are composing low-level tools/libs will enjoy @safe
guarantees. Only authors implementing ground-level machinery would
need to write @trusted code... and that's the nature of the whole
@safe stack.
@safe can't practically exist without @trusted at the bottom of the stack.

> Are there really no
> ideas?

I have some ideas, but I don't think they're practical to implement.
Some cross-referencing of access would be required for the compiler to
suspect foul-play.
Functions would need to be analysed in conjunction; that sounds hard
to implement.

> No check that the proper atomic funtions are used or the
> cast to "unshared" is ok at where it is used?

The user has manually cast to unshared inside their unsafe/(@trusted?)
function, what more signal do they need that they've engaged in an
unsafe operation?

> Even the expert
> needs a little help to find the upcomming and well hidden bugs in
> their oh so threadsave API...

I think a lot of people probably over-estimate the number of tooling
libs that live at the bottom of the stack.
The list is fairly short: Atomic, Mutex/Semaphore, and a couple of
lock-free-queue/list type structures.
I don't know what other useful constructs exist... they will all be in
libraries. Users would almost never come in contact with unsafe code,
and again, that's the whole point of my design!