Consider allowing static allocation of shared data whose affinity starts on a non-zero thread

[GoogleCodeExporter]

Discussion forked from issue 39:

I can see the utility of statically declaring scalars with non-zero affinity.  
I think the challenges in introducing such a feature would be:

1) devising appropriate syntax (and NOT overloading the blocking factor syntax 
which is already a sufficient source of confusion)
2) The current use of thread zero is convenient because it is already 
guaranteed to exist. We would need to think about how to handle programs in the 
dynamic thread environment that specify static allocation for threads which do 
not exist at runtime.

Anything we come up with would need to be balanced against the fact that this 
can already be easily accomplished using a statically-declared cyclic array and 
a pointer, although it wastes space. eg:
shared [1] int data[THREADS];
shared [1] int *B = &(data[4]); -- a pointer to a scalar on thread 4


Comment by Brian Wibecan from issue 39: 

Regarding static allocation of entities with non-zero affinity, I think this is 
a good question that should be broadened beyond scalars.

  shared int A;
  shared [] int B[12];

Both of these are allocated with affinity to thread zero.  If a means is 
devised for specifying A has affinity to some other thread, it should also be 
able to apply that to B.

  shared int C[10*THREADS];

And why not allow such a mechanism to state that C[0] has affinity to some 
thread other than zero?

So, food for thought for a future proposal.  I don't like the idea of singling 
out scalars for special treatment here.

Original issue reported on code.google.com by danbonachea on 16 Jun 2012 at 7:44

[GoogleCodeExporter]

I see possible use for both scalars and indefinite arrays allocated statically 
on threads other than zero.  However, I find it hard to imagine important cases 
that couldn't be resolved with dynamic allocation at start-up and something 
like the "upc_[all_]alloc_on_thread()" code in issue 39 (though use of 
broadcast should be more scalable that 
barrier+every-thread-reads-same-variable).

Original comment by [email protected] on 18 Jun 2012 at 10:41