I wish all qualifiers were revisited with an eye for simplification

[Manu]

On Thu, Aug 13, 2020 at 5:24 PM Jonathan M Davis via Digitalmars-d <
digitalmars-d at puremagic.com> wrote:

> 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


👍

You're right though! :P
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20200814/d77ede2e/attachment.htm>