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

Originally reported on Google Code with ID 53 ``` 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. ```

Reported by `danbonachea` on 2012-06-16 19:44:38

Comments (1)