<div dir="ltr"><div dir="ltr">On Thu, Aug 13, 2020 at 5:24 PM Jonathan M Davis via Digitalmars-d <<a href="mailto:digitalmars-d@puremagic.com">digitalmars-d@puremagic.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thursday, August 13, 2020 12:44:54 AM MDT Jonathan M Davis via Digitalmars-<br>
d wrote:<br>
> On Sunday, August 2, 2020 7:23:26 PM MDT Andrei Alexandrescu via<br>
> Digitalmars-d<br>
> wrote:<br>
> > On 8/2/20 6:55 PM, Stefan Koch wrote:<br>
> > > shared means simply: this is not thread local,<br>
> > > therefore this thing might be used by other threads<br>
> > > therefore you read or write it in an expression directly.<br>
> > > You can however have a function take a shared argument and leave<br>
> > > the scheduling or locking or whatever synchronization you use,<br>
> > > to enact an operation in a safe way.<br>
> ><br>
> > Yes, the intent was generous. The realization, not quite. However, I did<br>
> > learn from Walter that a number of invalid operations on shared numerics<br>
> > have now been disabled. However, copying a shared int into an int is<br>
> > allowed and as far as I know with no special treatment:<br>
> ><br>
> > <a href="https://run.dlang.io/is/ZP124F" rel="noreferrer" target="_blank">https://run.dlang.io/is/ZP124F</a><br>
> ><br>
> > At least on ARM that should generate a read barrier.<br>
><br>
> In princip@le, shared should be preventing any and all read-write operations<br>
> which it cannot guarantee are atomic (which probably means banning all<br>
> read-write operations, since that's going to vary across architectures).<br>
> All code with shared then either needs to either use atomics or cast away<br>
> shared and use mutexes, semaphores, or whatever other threading primitive<br>
> is appropriate to ensure that the data is only accessed by that single<br>
> thread while it's typed as thread-local, leaving it up to the programmer to<br>
> then ensure that they're dealing with the threading correctly (just like in<br>
> C++). However, unlike C++, all of the code operating on data shared across<br>
> threads would then be segregated (it would also likely be @system in most<br>
> cases). More complex objects can then have shared member functions which<br>
> deal with all of the threading stuff internally rather than requiring that<br>
> everyone using them deal with it directly, but at the core, it's ultimately<br>
> going to be a question of atomics or casts if we want the guarantee that<br>
> shared objects aren't being accessed across threads when they're not<br>
> properly protected.<br>
><br>
> However, the core problem with all of this is that the restrictions that<br>
> need to be put on shared have never really been put in place. For years,<br>
> about all that it really did was disallow implicit conversions between<br>
> shared and thread-local (and even then, it didn't always do it - e.g. with<br>
> integers). Over time, additional restrictions have been added (I think<br>
> mostly to numeric types), but it's all piecemeal. IIRC, there was a DIP that<br>
> was supposed to outright make reading and writing to shared variables<br>
> illegal, but I'm not quite sure where that stands. We also potentially need<br>
> some language improvements to make it cleaner, because otherwise in order<br>
> to read or write value types, we'll have to do stuff like take their<br>
> address and cast the resulting pointer so that we can operate on the object<br>
> as thread-local while the mutex is locked (or whatever or threading<br>
> protections are in place).<br>
><br>
> So, while I think that the basic idea of shared is solid, it's never been<br>
> properly implemented.<br>
<br>
LOL. And reading through the rest of the thread, I see that Manu already<br>
brought this up and that the DIP has an implementation with the -preview<br>
flag.<br>
<br>
- Jonathan M Davis</blockquote><div><br></div><div><span style="color:rgb(204,204,204);font-family:"Noto Color Emoji","Apple Color Emoji","Segoe UI Emoji",Times,Symbola,Aegyptus,Code2000,Code2001,Code2002,Musica,serif,LastResort;font-size:36px;text-align:center">👍</span> </div><div><br></div><div>You're right though! :P<br></div></div></div>