On Thu, Oct 18, 2018 at 6:50 PM Stanislav Blinov via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > > 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.
You are an obscene person. I'm out. You win.
