On Sun, Oct 21, 2018 at 3:15 PM Neia Neutuladh via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > > On Sun, 21 Oct 2018 12:04:16 -0700, Manu wrote: > > On Sun, Oct 21, 2018 at 12:00 PM Timon Gehr via Digitalmars-d > > <digitalmars-d@puremagic.com> wrote: > >> Note that there may well be a good way to get the good properties of MP > >> without breaking the type system, but MP itself is not good because it > >> breaks @safe. > > > > Show me. Nobody has been able to show that yet. I'd really like to know > > this. > > If we only used your proposal and only used @safe code, we wouldn't have > any data races, but that's only because we wouldn't have any shared data. > We'd have shared *variables*, but they would not contain any data we could > read or alter, and that's pretty much useless.
I've shown an implementation of Atomic(T) 3 times now... no response any time. Why is it being dismissed? Do I need to write it more times? This is a clear demonstration of how to build the foundation of the @safe threadsafe stack. > To use your proposal, we need to cast data back from shared to unshared. > When it's unshared, we need to make sure that exactly one thread has a > reference to that data as unshared. No, you just need to make sure that access is atomic or synchronised in a proper way, and if you do cast away shared in some low-level @trusted function, make sure that reference doesn't escape. You can do it, I have faith. > And @safe *should* help us with that. Totally. > Currently, it helps because casting unshared to shared is not @safe, > because it makes it trivial to get multiple threads with unshared > references to the same data. No no, that's a massive smell. That means anytime anyone wants to distribute something, they need to perform unsafe casts. That's not okay. Modeling shared-ness/unshared-ness is not *useful* in any way that I have been able to identify. Modelling what it means to be threadsafe is useful in every application I've ever written. 100% of my SMP code works with my proposal, and something close to 0% works with shared as it is today. (assuming we desire @safe interaction, which we do, because threading is hard enough already!) > And that's when you're using shared as > expected rather than doing something weird. No, I *expect* to use shared in @safe code, and not write any unsafe code ever. shared doesn't model a useful interaction now, not in any way. Today, access to shared data members are unrestricted and completely unsafe, passing data into something like a parallel-for requires unsafe casts.
