D2 Multithreading Architecture

[Michel Fortin]

On 2009-04-29 22:54:20 -0400, "Robert Jacques" <sandford at jhu.edu> said:

> On Wed, 29 Apr 2009 21:25:32 -0400, Michel Fortin  
> <michel.fortin at michelf.com> wrote:
> 
>> That's basically why I suggested adding scope constrains back then. To 
>> implement swap safely, you need to know that the scope of the pointer 
>> you are assigning to is always smaller or equal to the scope of the 
>> memory block you're feeding them with.
>> 
>> Here's a new syntax for expressing contrains I've been thinking about:
>> 
>> 	void swap(scope int* x, scope int* y)
>> 	  scope(x = y && y = x)  // caller enforces that y is assignable to x 
>> and x to y
>> 	{
>> 		scope(x = t && t = y) int* t;
>> 		// y assignable to t and t to x; also imply that
>> 		// x is assignable to y, which holds against previous constrains
>> 
>> 		t = y;  // valid since scope(t = y)
>> 		y = x;  // valid since scope(y = x)
>> 		x = t;  // valid since scope(x = t)
>> 	}
>> 
>> Perhaps with simple escape analysis, the compiler could infer the scope 
>> constrains of local variable t so you don't have to write it everywhere.
> 
> You know, the implementation of swap is really a bad example, since 
> using  a template works fine:
> void swap(T)(ref T x, ref T y) {
>      T t
>      t = y;
>      y = x;
>      x = t;
> }

You know, all functions could be made templates and it'd solve all our 
problems. Why aren't we doing that?

Seriously, templates can't be the answer to everything. What if you 
wanted swap as a member function of a class, and want to override it in 
a derived class? We need a system that works with non-templates too.


> Object a;
> Object b;
> shared Object c;
> swap(a,b);   // Okay
> swap(b,c);   // Error, template instantiation swap(local object, shared 
>  object)

In the case of my function with constrains you'd get something alike:

	swap(b,c); // Error, 'swap' wants c (shared Object c)
	// to be assignable to b (local Object b) which isn't allowed.

Basically, you can't copy a scope variable to another scope variable 
inside a function (because they may not be of the same scope and/or 
ownership) unless the signature includes a constrain signaling the 
assignement, which is then evaluated at the call site.


> Here are some specific issues:
> 1) You seem to assume that different ownerships are interchangable. 
> They  are not. Even if the data layout and member signatures are the 
> made to be  the same, shared objects must maintain sequential 
> consistency (i.e. memory  fences).
> 1a) Limiting object signatures to being identical makes it hard for  
> library writers to make a class that can be both allocated on both the  
> shared and local heaps.

Where am I assuming that? How? Perhaps I'm not understanding something 
of your proposal, but I don't see how adding scope constrains breaks 
shared objects.

You say you want "scope" to be the super-type of all, which means that 
it should accept both local and shared variables, am I right? If that's 
the case I was right to write variable as being scope in my swap 
function, so it can accept everything.


> 2) You shouldn't rely on escape analysis to determine your function  
> signature. It essentially forces you to do whole program static escape  
> analysis, if you want to do it right, which is implausible. Consider  
> recursive and member functions. What's the proper signature? And this  
> isn't even considering the composability and forward referencing issues.

That I certainly agree with. (And I never suggested escape analysis to 
determine the scope of function arguments, only local variables inside 
the function.)


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