[dmd-concurrency] shared arrays

[Andrei Alexandrescu]

Michel Fortin wrote:
> Le 2010-01-14 à 22:01, Andrei Alexandrescu a écrit :
> 
>> Michel Fortin wrote:
>>> Le 2010-01-14 à 18:07, Andrei Alexandrescu a écrit :
>>>> Unfortunately, this(this) is called after the bits have been
>>>> copied, so if there was any tearing, it already happened. I don't
>>>> know how we can solve this.
>>> Where is the copy-constructor when we need one? :-)
>> I realized that fortunately that's not a problem: during memcpy, the target is not yet shared. Whew. So it all holds water.
>>
>> this(this) shared { ... }
>>
>> should work.
> 
> But the source is shared. Couldn't it be updated while memcpy does its work, creating an incoherent state? Something like: memcpy copies half of it, context switch, other thread update first and last bytes, context switch, memcpy finishes its work. Result, last byte of the copy doesn't match first byte.

I just meant that we're not constrained by the memcpy prior to this(this).

I don't know whether we should disallow such copies. Probably we should, 
but I don't have a strong case. If we disable it, cowboys will be 
unhappy. If we enable it, others will.

The problem is, if we disable even "this(this) shared" there's no chance 
to copy a shared object, even if you're willing to fix the inconsistencies.

>>> Now, the really tricky question is should this one be copyable when
>>> shared:
>>> struct D { immutable string a; long b; }
>>> Since 'a' is immutable, you don't need to copy it atomically, only
>>> 'b' requires an atomic copy. So copying the struct "atomically" is
>>> possible by copying 'a' normally and 'b' atomically. Now, is that
>>> going to be supported?
>> But long isn't atomically copyable. Did you mean int?
> 
> Well, that depends on the architecture. I meant a type which is atomically copyable yes.

Speaking of which: is it reasonable to assume that all 32-bit modern 
architectures have a 64-bit atomic assign? How about 64-bit atomic CAS?


Andrei