shared - i need it to be useful
Manu
turkeyman at gmail.com
Fri Oct 19 01:22:53 UTC 2018
On Thu, Oct 18, 2018 at 3:10 PM Simen Kjærås via Digitalmars-d
<digitalmars-d at 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.
More information about the Digitalmars-d
mailing list