Generality creep

[Manu]

On Wed, Apr 3, 2019 at 7:10 PM Andrei Alexandrescu via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> On 3/31/19 6:25 PM, Manu wrote:
> > On Sat, Mar 30, 2019 at 5:45 PM Andrei Alexandrescu via Digitalmars-d
> > <digitalmars-d at puremagic.com> wrote:
> >>
> >> On 3/30/19 2:49 PM, Jonathan M Davis wrote:
> >>> This would also be a great opportunity to fix some of the issues with shared
> >>> in druntime
> >>
> >> The problem here is, of course, that nobody knows exactly what shared is
> >> supposed to do. Not even me. Not even Walter.
> >
> > As an immediate stop-gap, shared must have *no read or write access*
> > to data members. Simple. Make that change. Right now.
> > Then shared will at least be useful and not embarrassing, and you can
> > continue to argue about what shared means while I get to work.
> >
> >> One monumental piece of work would be DIP 1021 "Define the semantics of
> >> shared". Then people who build with -dip1021 know what to do and what to
> >> expect. Now that would patch one of the bigger holes mentioned in the
> >> other post.
> >
> > Sure. But in the meantime, fix the objective bug with the current
> > semantics where you can read/write un-protected data freely. Right
> > now. Please for the love of god.
>
> Incidentally Walter and I discussed in the early days the idea that
> "shared" would offer no access whatsoever aside from a few special
> functions in druntime such as "atomicRead" and "atomicWrite". Of course,
> that raised the question how those functions could be implemented - the
> possible solution being some casts for typing and asm for the needed
> memory barriers.

Casting away shared seems to be the only reasonable option with
respect to this general design for shared.

This applies just fine to atomics; casting away shared is effectively
asserting that you have created a thread-local context for some window
of time that you can perform a thread-safe interaction.
Atomic operations have an effective zero-length execution window, so
from that perspective, it's correct that you are able to cast-away
shared in order to perform a single atomic operation on an int. The
assertion that you have a thread-local lease on the int for the
duration of an atomic operation naturally holds by definition.

> In the end we got scared that there was no precedent in other languages,
> and we could not predict whether that would have been good or bad. The
> result is the current semantics, which should be a felony in the 48
> contiguous US states.

Okay... so you're effectively saying you had a possibly-good idea, but
instead of trying it, instead did something else that's just
straight-up broken?
So, like, how about we actually try the thing before we decide it
didn't work? We have nothing to lose!

> This does not work as a two stages process, though the "stop the
> bleeding first then come with the new solution" metaphor seems
> attractive.

You're saying a design was proposed, and it's *almost* implemented in
the language. It's been there for longer than I've been around, but
we're still yet to actually try out the design as is almost
implemented so long ago. It's really weird that we're declaring the
design failed before trying it out! We've had, like... 12 years to try
it out? Why haven't we tried it yet?

We're not bleeding from a failed design. If there is a wound in place,
it's the fact that the intended design was only half-implemented, and
then left that way for over a decade.

Making this change would give something to work with. If it turns out
it's not a workable solution after all, then it would be good to know
before we eject it into space!
Better design may emerge from understanding how this design failed.
But it hasn't failed yet, because we haven't actually tried it yet...
it's just been sitting in limbo waiting while people scratch their
head and try to understand what happened here.

That process is surely more useful than the current situation, which
is that `shared` means nothing, and nobody quite knows what it's for
other than a sort of self-documentation.

I understand you may prefer a strong design proposal, but nobody has
moved the bar in the decade I've been waiting.
We're clearly not making ground in the way you prefer, so let's just
actually implement the design almost-implemented 12(+?) years ago, and
see how terrible it actually is?

I have a fairly strong sense of what will emerge, I suspect it'll be
workable and useful.

> The main issues being when we break code that people got to
> work, we need to offer the alternative as well. Another being that the
> exact kind of things we disable/enable may be dependent on the ultimate
> solution.

I'm fairly sure we're not 'breaking' anything. Any code that breaks
with this change is almost certainly already broken.
The remedy would be to add a cast to their code, and it will be
exactly as it is now; probably still broken. But it's really not very
disruptive.

> This would be a large effort requiring a strong team. Walter, yourself,
> and I would be helpful participants but I think between the three of us
> we don't have the theoretical chops to pull this off. At least I know I
> don't. We need the likes of Timon Gehr, Johan Engelen, and David
> Nadlinger (whom I cc'd just in case).

Go for it... but like, maybe first, how about we actually try out the
design you came up with 12 years ago before we declare it a failure
and spend another few years trying to do something else?
We have no evidence it's a failure, only that the half-implementation
of the original design is a failure, and mostly for the reason that
the half-semantics just don't mean anything, not that the original
idea is broken.