[dmd-concurrency] shared arrays

[Steve Schveighoffer]

----- Original Message ----

> From: Michel Fortin <michel.fortin at michelf.com>
> To: Discuss the concurrency model(s) for D <dmd-concurrency at puremagic.com>
> Sent: Fri, January 15, 2010 8:20:48 AM
> Subject: Re: [dmd-concurrency] shared arrays
> 
> 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.


It depends on how you define "work right."  I don't think shared is meant to fix all race issues.  It can't possibly in fact, because you can simply decompose a shared copy to get the erroneous behaviour you want to prevent:

struct T
{
   int x;
   int y;
}

shared(T) t;

void foo()
{
   //T myt = t; // oops, compiler doesn't let me do this, I'll work around:
   T myt(t.x, t.y);
}

> 
> 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);

It's an artificial limitation -- the copy is still possible, just the syntax will suck.

Now, with the new @disable property, you can force users to call your thread-safe implementation without resorting to this(this).  Then you can create a truly contained thread-safe type.  So I think it's ok to allow this(this) in cases where developers want to optimize or are sure the type is uniquely accessible (via an external lock).  I think it's better for the compiler not to make assumptions about what the semantic meaning of a struct or array is.

-Steve