[dmd-concurrency] shared arrays

[Robert Jacques]

On Fri, 15 Jan 2010 08:20:48 -0500, Michel Fortin  
<michel.fortin at michelf.com> wrote:

> Le 2010-01-14 à 22:20, Andrei Alexandrescu a écrit :
>
>> Michel Fortin wrote:
>>> 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.
>
> I think we should disable it. It's much easier to add the feature later  
> when we have a proper solution than removing a feature later because it  
> doesn't work right.
>
> Also, saying there is no chance to copy a shared object is a bit much.  
> You can always define your own copy function, or a "copy constructor"  
> (that you'd have to call explicitly):
>
> 	struct A {
> 		int a, b, c;
> 		this(const ref shared A) {
> 			...
> 		}
> 	}
>
> 	shared A a1;
> 	A a2 = A(a1);
>
>
>> 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?
>
> No idea, but I doubt it.
>
> You could probably do atomic read and writes using the floating point  
> registers (at the risk of raising a floating point exception), but  
> that's a little contorted.

 From wikipedia:
"Early AMD64 processors lacked the CMPXCHG16B instruction, which is an  
extension of the CMPXCHG8B instruction present on most post-486  
processors. Similar to CMPXCHG8B, CMPXCHG16B allows for atomic operations  
on 128-bit double quadword (or oword) data types. This is useful for  
parallel algorithms that use compare and swap on data larger than the size  
of a pointer, common in lock-free and wait-free algorithms. Without  
CMPXCHG16B one must use workarounds, such as a critical section or  
alternative lock-free approaches"

So while 32-bit and 64-bit CPUs should have a 64-bit CAS, some 64-bit CPUs  
won't have a 128-bit CAS. And since so many things (like arrays) go from  
64-bits to 128-bits when you switch from 32-bit DMD to 64-bit DMD, I think  
assuming the presence of a double width CAS to be erroneous in the  
language design.