I wish all qualifiers were revisited with an eye for simplification

[Jonathan M Davis]

On Thursday, August 13, 2020 12:44:54 AM MDT Jonathan M Davis via Digitalmars-
d wrote:
> On Sunday, August 2, 2020 7:23:26 PM MDT Andrei Alexandrescu via
> Digitalmars-d
> wrote:
> > On 8/2/20 6:55 PM, Stefan Koch wrote:
> > > shared means simply: this is not thread local,
> > > therefore this thing might be used by other threads
> > > therefore you read or write it in an expression directly.
> > > You can however have a function take a shared argument and leave
> > > the scheduling or locking or whatever synchronization you use,
> > > to enact an operation in a safe way.
> >
> > Yes, the intent was generous. The realization, not quite. However, I did
> > learn from Walter that a number of invalid operations on shared numerics
> > have now been disabled. However, copying a shared int into an int is
> > allowed and as far as I know with no special treatment:
> >
> > https://run.dlang.io/is/ZP124F
> >
> > At least on ARM that should generate a read barrier.
>
> In princip at le, shared should be preventing any and all read-write operations
> which it cannot guarantee are atomic (which probably means banning all
> read-write operations, since that's going to vary across architectures).
> All code with shared then either needs to either use atomics or cast away
> shared and use mutexes, semaphores, or whatever other threading primitive
> is appropriate to ensure that the data is only accessed by that single
> thread while it's typed as thread-local, leaving it up to the programmer to
> then ensure that they're dealing with the threading correctly (just like in
> C++). However, unlike C++, all of the code operating on data shared across
> threads would then be segregated (it would also likely be @system in most
> cases). More complex objects can then have shared member functions which
> deal with all of the threading stuff internally rather than requiring that
> everyone using them deal with it directly, but at the core, it's ultimately
> going to be a question of atomics or casts if we want the guarantee that
> shared objects aren't being accessed across threads when they're not
> properly protected.
>
> However, the core problem with all of this is that the restrictions that
> need to be put on shared have never really been put in place. For years,
> about all that it really did was disallow implicit conversions between
> shared and thread-local (and even then, it didn't always do it - e.g. with
> integers). Over time, additional restrictions have been added (I think
> mostly to numeric types), but it's all piecemeal. IIRC, there was a DIP that
> was supposed to outright make reading and writing to shared variables
> illegal, but I'm not quite sure where that stands. We also potentially need
> some language improvements to make it cleaner, because otherwise in order
> to read or write value types, we'll have to do stuff like take their
> address and cast the resulting pointer so that we can operate on the object
> as thread-local while the mutex is locked (or whatever or threading
> protections are in place).
>
> So, while I think that the basic idea of shared is solid, it's never been
> properly implemented.

LOL. And reading through the rest of the thread, I see that Manu already
brought this up and that the DIP has an implementation with the -preview
flag.

- Jonathan M Davis