[dmd-concurrency] shared arrays

[Michel Fortin]

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.


-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/