shared - i need it to be useful

[Stanislav Blinov]

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 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.

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.