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

[Manu]

On Sun, Oct 13, 2019 at 12:55 AM Ola Fosheim Grøstad via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> On Sunday, 13 October 2019 at 04:09:26 UTC, Jonathan M Davis
> wrote:
> > The compiler is free to assume that anything that isn't shared
> > is thread-local and optimize code accordingly.
>
> That has no real effect though, if you throw away shared before
> using it.
>
> 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.
Thread's don't have 'states', that's literally the point of threads!
No code-gen can ever assume any stateful details of any kind about
another thread.
Maybe there's a 10 year research project there, but that idea is so
ridiculous and unlikely to work that nobody would ever try.

I think what you're talking about is something more like a framework;
where different threads are running known code which is configured to
cooperate in particular ways, and implements safe data transmission
between threads.
This is what will exist, there will be elaborate libraries of this
kind. I don't expect many end-users would ever encounter a `shared`
object, it would likely be behind the curtains in all cases, unless
they're writing very low-level systems.

> But that is not on the table...

Definitely not. Not at the language level at least.