[dmd-concurrency] shared arrays

[Steve Schveighoffer]

----- Original Message ----

> From: Michel Fortin <michel.fortin at michelf.com>
> 
> Le 2010-01-14 à 7:10, Steve Schveighoffer a écrit :
> 
> > 
> > What happens in cases like this:
> > 
> > shared(S)[] arr3;
> > arr3[] = arr2[];
> > 
> > any ideas of how this can be resolved?  Should shared arrays enjoy all the 
> operations that normal arrays have?
> 
> Well, you need a lock.

Whatever locks that must be taken must also be taken any time an array is accessed.

For instance you'd need to take the same lock when doing:

arr2[3].x = 5;

I don't think this is a workable solution.

This is the same solution I erroneously used when doing a shared append -- I created a global lock for appends to all shared arrays.  This works to synchronize appending, but writes to the array from another thread would compromise the integrity of the data.

> Perhaps the runtime could maintain a shared pool of locks for those operations. 
> You'd need to first hash the address of the allocated memory block (which is not 
> necessary the first element, so you'll need the GC to tell you). This hash gives 
> you the index of a mutex in the pool to use, the idea being that it's always the 
> same mutex for a given memory block. Some memory blocks will share the same 
> mutex, but if the pool is big enough two threads wanting the same mutex for a 
> different memory block shouldn't happen too often.
> 
> The copy operation can't take any other lock though, or else you risk having 
> deadlocks. This might be a problem when copying a struct.

You can ensure the order of locks by sorting them (if you need 2 locks at once).

But again, I'm not sure how this prevents having to take a lock on every access to any array data, which makes the system not really scale well.  I think we may need to find a way to do this without locks (i.e. use shared semantics) or else disallow these kinds of operations on shared arrays.  Just using shared semantics would not prevent all corruption issues, but I think at that point a lock-protected array library type is in order.

The one problem I still have no idea how to solve is the "partially shared" element type as T is:

struct T
{
   shared int x;
   int y;
}

-Steve