I wish all qualifiers were revisited with an eye for simplification

[Jonathan M Davis]

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.

- Jonathan M Davis