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. 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. If the functions used mutexes, or semaphores, exactly the same applies; they are either function calls (not reordered), or they use hardware primitives, which have scheduling fences. If none of those things are present in the threadsafe functions, then the functions aren't threadsafe in the first place! In short, he made up this issue, it doesn't exist. > 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. 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. This is just hot air, and only strengthen my conviction.
