DIP 1024--Shared Atomics--Community Review Round 1

[Manu]

On Sun, Oct 13, 2019 at 2:10 PM Ola Fosheim Grøstad via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> On Sunday, 13 October 2019 at 19:23:45 UTC, Manu wrote:
> > Your insistence that shared should be a library thing applies
> > equally
> > to const. It behaves in an identical manner to const, and if
> > you can't
> > make a compelling case for moving const to a library, you can't
> > possibly sell me on that idea with respect to shared.
>
> I'm not trying to sell anything, but you cannot easily implement
> D's const using metaprogramming as metaprogramming is realized in
> D.
>
> You can easily extend the metaprogramming capabilities of D to
> implement shared.
>
> Apples and Oranges.

How so?
`shared` is exactly like const, but with an additional restriction
that you can't read either.

> > 1. `shared` defines D's thread-local by default semantics...
> > without
> > shared, there is no thread-local by default. That decision is
> > so deep,
> > there is absolutely no way to move away from that.
>
> That argument makes no sense to me. Thread local or not thread
> local is essentially only by social agreement if you have
> syntactical means to get around it.  It is predominantly a social
> contract.

"if you have syntactical means to get around it" <- this is `shared`;
if we lose shared, we lose thread-local.

> It is a matter of agreement, interpretation, conceptualization,
> mindset... That is what defines what is thread local in D. Not
> machinery.

Yeah, but if there's no way to describe not-thread-local, then
thread-local doesn't really mean anything.
Assuming there were no shared, and "data is thread-local" is
specified, then you'd be doing UB anytime you spawn a second thread...
then the language would just need to tolerate that, and accept that
so-called thread-local data may or may not actually be thread-local
(and conservatively assume not thread-local), because no way to
distinguish.
I mean, I understand your point of view, but in practical terms, it's
not correct. thread-local by default exists because `shared` exists.

> > 2. We must be able to overload on `shared`. We can't 'overload'
> > on
> > template wrappers; we can try and specialise and stuff and abuse
> > clever inference and type deduction, but things break down
> > quickly. I
> > have tried to simulate type qualifiers with template wrappers
> > before.
> > It always goes *very* badly, and it's a mess to work with.
>
> You have two alternatives:
>
> 1.  you can do a simple one with template wrappers.

It goes very badly every time I've tried this.

> 2. you can extend the meta programming capabilities and have a
> more advanced  solution that is more in line with the current
> syntax

That's a huge development, and much uncertainty.
And it's not like we're introducing shared here... he's been in D
forever, we're just making it mean something.

> But it certainly is possible, and not very hard to envision.
> After all making something completely unavailable, is much easier
> than only making some aspects of an object unavailable. Which is
> why "shared" is relatively easy to do on the syntactical level in
> D, but "const" is harder.

I don't understand... I think they're almost identical hard-ness.

> > 3. Most importantly, there is a future (not shown in this
> > discussion)
> > where shared should allow some implicit promotions safely; for
> > instance:
>
> Ok, not sure if that really impacts whether it can be done in a
> library or not, but it certainly is VERY important to list such
> use-cases with sufficient detail when designing foundational
> mechanisms that is supposed to enable good interfaces to
> parallell programming libraries!

We're not designing foundational mechanisms, Walter designed shared
decades ago and it's firmly embedded in the language. We're just
making it not completely broken right now.
Designing a better shared is future work, which needs to start from
stable ground.