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

[Manu]

On Mon, Oct 14, 2019 at 5:50 AM Ola Fosheim Grøstad via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> On Sunday, 13 October 2019 at 19:08:00 UTC, Manu wrote:
> > On Sun, Oct 13, 2019 at 12:55 AM Ola Fosheim Grøstad via
> > Digitalmars-d <digitalmars-d at puremagic.com> wrote:
>
> >> That said, if you had a formalization of the threads and what
> >> states different threads are in then you could get some
> >> performance benefits by eliding shared overhead when it can be
> >> proven that no other threads are accessing a shared variable.
> >
> > What does that even mean? You're just making things up.
>
> (Drop the ad hominems... Especially when your in an area that is
> not your field.)

Threading and synchronisation is exactly my field.

And it's not at hominem, I really do think you're just making stuff up
(although I'm sure informed by ideas in competing ecosystems)... I'm
sure you mean well and have some great idea, but you haven't presented
anything that I can think on.
The closest thing you've said to a real implementation proposal so far
is strong-ownership based message passing like rust, but that's not
really in contest with this DIP, and I can't imagine how `shared`
would have any influence on that toolbox.

> > Thread's don't have 'states', that's literally the point of
> > threads!
>
> All program execution is in a state at any given point in time.
>
> So yes, you transition between states. That is the premise for
> building an advanced type system. That's what makes it possible
> to implement Rusts borrow checker.

That's all thread-local concepts. There's nothing reasonable you can
determine between threads without synchronising the threads.
D is flirting with escape analysis, we have `scope` and `return` and
things like that, and those are the things that will eventually allow
us to do in-language transitions to/from shared without unsafe casts.

> Anything that moves in a discrete fashion will move between
> states, that is a basic computer science conceptualization of
> computing. It is the foundation that theories about computing is
> built on.

The only reasonable CS model of threading I've ever seen requires you
to start talking about strong ownership and transfering ownership
between threads.
While I agree that strong ownership and message passing is robust and
worth having in any async ecosystem, it's also tremendously
inefficient for certain workloads, and if that were all we had baked
into the language, it excludes other (useful) possibilities.

> > Maybe there's a 10 year research project there, but that idea
> > is so
> > ridiculous and unlikely to work that nobody would ever try.
>
> Oh. People do it. Sure, it is hard in the most general case, but
> you do have languages with high level concurrency constructs that
> provide type systems that makes it possible to write provably
> correct concurrent programs.

That's not so much language at that point, it becomes blessed library,
or a 'framework' even.
Point me to some examples which are more than in-language message passing?
I don't think we're excluding those sorts of solutions from D.

> It doesn't make much sense to claim that nobody would ever try to
> build something that actually exists... Does it?

The way you initially described the premise was something along the
lines of "the language knows the *state* of interacting threads and
does magic thread-safe stuff", which I'm skeptical exists anywhere
without a very elaborate framework to manage any such orchestration.
I think now that you might be talking about ownership and message
passing... but it's still not clear. What are you actually talking
about? Do you have references?

Incidentally, my code that I linked to back up this thread is
effectively an implementation of a rust-like shared object where it
maintains a 'borrow' ref count, and guards access safely... it's easy
to write those tools in D.

> > I think what you're talking about is something more like a
> > framework;
>
> No. Languages/compilers that check concurrency states at compile
> time.

Show me. That is exactly the opposite of what threads are for :/
I can't imagine it, and if a _language_ did that, it almost certainly
comes at a high cost, and it's almost certainly not what I want it to
do... but I'm willing to be surprised.

> >> But that is not on the table...
> >
> > Definitely not. Not at the language level at least.
>
> That's right. So those benefits are not avilable... which was my
> point. :-)

I can't predict what you're talking about, and you haven't shown
anything substantial. I suspect if you show what you mean, I may find
the term 'benefits' to be problematic ;)