On Friday, 19 October 2018 at 01:22:53 UTC, Manu wrote:
On Thu, Oct 18, 2018 at 3:10 PM Simen Kjærås via Digitalmars-d
<digitalmars-d@puremagic.com> wrote:
Now, Two very good points came up in this post, and I think
it's worth stating them again, because they do present
possible issues with MP:
It is easy to respond to these.
1) How does MP deal with reorderings in non-shared methods?
I don't know. I'd hide behind 'that's for the type implementor
to handle', but it's a subtle enough problem that I'm not
happy with that answer.
This is a red-herring. Opaque function calls are never
reordered.
If they are inlined, the compiler has full visibility to the
internal machinery present.
You don't say?.. And what, exactly, stops the optimizer from
removing "unnecessary" reads or rearranging them with stores,
given the original code, which, if you freaking read it, you'd
see there's no indication that it's not allowed to do so.
If you call one function that performs an atomic op, then
another that performs an atomic op, it is impossible for the
CPU to reorder atomic op's around eachother, that would defeat
the entire point of hardware atomic operations.
I'm not talking about CPU reordering at all. I'm talking about
the optimizer.
In short, he made up this issue, it doesn't exist.
Yeeees, of course I have. What else have I made up, can you tell?
You know what doesn't exist though? Even one example of a useful
implicit conversion form mutable to shared from you. Not even one.
2) What about default members like opAssign and postblit?
The obvious solution is for the compiler to not generate these
when a type has a shared method or is taken as shared by a
free function in the same module. I don't like the latter part
of that, but it should work.
These aren't issues either. There's nothing wrong with atomic
assignment; you just have to implement an atomic assignment.
You just haven't read the code. Those members aren't even
`shared`. The *least* you can do is disable them *if* you're
going to cast your variable to `shared`. Otherwise your
"interface" remains non-threadsafe.
Postblit is being replaced with copy-ctor's and `shared` is one
of the explicit reasons why! Copy-ctor's are also fine, it
would express an atomic assignment.
And this strengthens *my* belief that you haven't at all thought
about this. There is literally *no* purpose for any `shared`
types to have any copy-ctors. The only feasible copy primitives
are from shared to local and from local to shared. Not to mention
that again, to even talk about your "implicit" conversions, you
must first think about what can happen to the *owned*
(non-`shared`) reference after the conversion. Hint: you can't
copy it. You can't assign *to it*. Not via default-generated
postblits and opAssigns, which are not, and can not, be "atomic".
I'm fully aware about postblits being "replaced" by copy-ctors,
I'm also fully aware how "much" thought was put into that wrt.
`shared`.
This is just hot air, and only strengthen my conviction.
You know what, I'm fed up with you too. Just show me one, *one*
non-contrived example of useful implicit conversion from mutable
to shared. So far you haven't produced *any at all*. Then we can
talk about what is hot air here. Produce, or drop this
presumptious crap.
