[dmd-concurrency] shared arrays
Michel Fortin
michel.fortin at michelf.com
Thu Jan 14 18:49:07 PST 2010
Le 2010-01-14 à 18:07, Andrei Alexandrescu a écrit :
> struct A { int a, b; }
>
> shared A x, y;
> x = y; // yay or nay?
>
> I think this should be allowed. This is because A makes no attempt to protect its data by e.g. defining a copy constructor. Anyone could modify a, b in any way - so why not different threads?
That's fine *if* you can read and write atomically. So you need 64-bit atomic reads and writes, otherwise it shouldn't compile.
> Finally, consider this case:
>
> struct C {
> int a;
> long b;
> ...
> }
>
> I'd argue that shared objects of this type shouldn't be copyable.
I agree.
> What if it adds a shared constructor?
>
> struct C {
> int a;
> long b;
> this(this) shared { ... }
> }
>
> 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? :-)
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?
--
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/
More information about the dmd-concurrency
mailing list