[dmd-concurrency] is shared going to be a type modifier?

[Steve Schveighoffer]

----- Original Message ----

> From: Michel Fortin <michel.fortin at michelf.com>
> Le 2010-01-07 à 15:34, Steve Schveighoffer a écrit :
> 
> > In fact, any shared class reference on the stack erroneously will create 
> memory barriers around the stack variable itself -- you shouldn't be sharing any 
> stack data.
> 
> I'm not sure you should never be sharing stack data. Stack data can already be 
> allocated on the heap with closures. If you're going to give that closure to 
> another thread, the data it uses needs to be shared.

If you pass a closure to another thread, the whole stack frame should be marked as shared because you are passing the whole stack frame.  The only reason to mark individual variables as shared is if you are passing addresses of individual variables to other threads, which you shouldn't do.

e.g.:

void foo()
{
  int x;
  shared int y;
  void subfoo()
  {
     x++;
    atomic(y++);
  }
  passToOtherThread(&subfoo);
}

The other option is to mark an inner function somehow so it can *only* access shared variables, and then it somewhat makes sense, but I don't see that it's an important feature.  Allowing shared stack variables seems to be erroneous in most cases, and causes too much confusion for the sake of some bizarro delegate scheme.

You also would never ever allocate such a function frame on the stack :)  At least the shared portions.

In fact, I'd suggest that any time you see this:

void foo()
{
   int x;
   shared int y;
}

It's either a compiler error, or the portion of foo's stack frame that contains y should always be globally heap-allocated.  It is acceptable to allocate x on the stack, but it can go into the heap frame if it makes things easier.  However, delegates which access x have to be unshareable (but could access y through normal shared means).

-Steve