On 7/3/06, Gary Funck <[EMAIL PROTECTED]> wrote: ...
Operations on UPC's shared objects have different semantics than regular "C". Array indexing and pointer operations span threads.
Thus A[i] is on one thread but A[i] will (by default) take you to the next (cyclic) thread. Since the semantics are different,
This is a totally off-topic, but the layout in UPC doesn't really affect the semantic. The layout, or the distribution, is primarily there for the performance, not for the correctness. And it really doesn't behave any differently (except for the extra restrictions and checks put there to make programmers think about data distribution across threads). A[10] is A[10], or the tenth element of the array A regardless of which thread has the affinity to the element. That's actually the whole point of UPC - that the code is mostly semantically same as regular C. But that's grossly off-topic so please don't do any followup on this.
the programmer needs to know that -- it affects the API. TLS objects behave like regular "C" objects, at least from the perspective of the referencing thread.
They don't behave the same way from any perspective. Non TLS can change underneath by other threads, whereas TLS can not (except when the pointer to a TLS has escaped to other threads, which UPC prevents by extra casting restriction on shared and private pointers). It has a serious impact on how you code around the variable - whether you need locking and/or some sort of atomic update or not, whether you can use it to communicate between threads or not, how the variable is initialized, etc. Or, since you seem familiar with UPC: In UPC: int local_counter; shared int global_counter; is exactly semantically equivalent to: int __thread local_counter; int global_counter; in C99 w/ __thread extension. Your proposal is equivalent, in UPC, like allowing declaring a global variable as private, and then later turn it into a shared in the definition, or vice versa. -- #pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com";
