std.functional.memoize : thread local or __gshared memoization?

[Jonathan M Davis via Digitalmars-d]

On Thursday, May 25, 2017 10:41:23 Andrei Alexandrescu via Digitalmars-d 
wrote:
> On Thursday, 25 May 2017 at 03:51:05 UTC, Stanislav Blinov wrote:
> > On Thursday, 25 May 2017 at 01:17:41 UTC, Timothee Cour wrote:
> >> thanks; i think docs for this should still make that clear.
> >>
> >> How about adding memoizeShared for shared variables?
> >> There definitely are use cases for this.
> >
> > Perhaps we should first actually properly document and
> > implement what shared *is*.
>
> I'm looking into creating a small interest group composed of
> experts to lead this effort. We'd put a DIP together that nails
> down shared. Who is interested? -- Andrei

I would be, though it is one of those topics where you think that you know
what you're doing, and then you find out about some compiler optimization or
other low level item that you don't know about, and some of what you thought
was true wasn't. So, this is one area where I'm not sure that I'd ever be
willing to call myself an expert no much how much I knew.

But we do need to get this ironed out well enough that we can definitely
tell folks that shared is what it's going to be so that they'll stop using
__gshared all over the place to try and work around shared - or at least if
they do so, they won't be able to do so with the excuse that shared is not
complete. But the idea that you do almost nothing with an object that is
shared without casting it first (after protecting it appropriately with a
mutex of course) except for using atomics seems to be too much for many
folks, even though aside from the cast, the way you actually use a shared
object is basically what you'd do in C/C++. I'd say that ultimately, shared
is more for storing the object and protecting it against operations that
could operate on it incorrectly than it is for actually operating on the
object. Unfortunately, synchronized classes are the only construct that
we've come up with that allows for the locking and casting to to be done
safely and automatically rather than requiring an explicit cast, and not
only do we not have synchronized classes yet, but even if we did they would
only work on the outer layer of shared, so in many cases, you'd be forced to
cast anyway.

I think that ultimately the big problems that we need to solve are making it
clear what shared is and how you use it and ensuring that we have the memory
model stuff ironed out well enough that the required casting and other
operations are actually guaranteed to do what they're supposed to do. Then
it's an issue of educating folks about shared rather than needing to fix
anything about it. I don't expect that shared will never be entirely pretty,
but ultimately, it's a lot like @safe/@system/@trusted in that it allows you
to segregate the code that you need to worry about for a particular class of
problem - and ultimately, the biggest benefit of shared is that everything
else is thread-local.

- Jonathan M Davis