On Sunday, 21 October 2018 at 22:12:18 UTC, Neia Neutuladh 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,
Only of the @trusted implementation is thread safe, which it
_should_ be. This is the same caveat as non threaded
-@safe/@tusted code.
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
Reads must be atomic.
or alter, and that's pretty much useless.
To use your proposal, we need to cast data back from shared to
unshared.
Yes but this is in the @trusted implementation that forms the
basis of your threadsafety.
When it's unshared, we need to make sure that exactly one
thread has a reference to that data as unshared.
Nod.
And @safe *should* help us with that.
Nod.
Currently, it helps because casting unshared to shared is not
@safe,
This remains the case, and should be done (enforced by the
compiler) only in @trusted/@system code as a basis for thread
safe, @safe code.
because it makes it trivial to get multiple threads with
unshared references to the same data.
That is @trusted or @system code and therefore is the programmers
responsibility.
And that's when you're using shared as expected rather than
doing something weird.
That forms the basis of your thread safe stack. From there on,
the basis that shared arguments to functions are treated safely
in the presence of threading means that code that calls the
@trusted implementations is @safe.
