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