Seongbae Park wrote: > In UPC, anything that's not TLS (or in UPC term, "private") > is marked explicitly as "shared". So it's NOT trasparent in > any sense of the word. > See, you have two choices - either > 1) make every global variable TLS by default and mark only > non-TLS (UPC) or > 2) vice versa (C99). > > It is not sane to allow TLS/non-TLS attribute changing underneath you > - which is what you proposed.
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, 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. Note that this discussion started only on the question as to whether the compiler should issue an error if it sees a bare extern referencing a __thread object. My position is that it should be a target dependent error, and perhaps only a warning (because on some platforms the resulting program will link and execute as expected), and that there are many commonly occurring cases where the compiler can't catch the inconsitencies in declarations and these are left for the linker anyway. Also note that the proposed specification seems to side-step the issue by only allowing __thread after extern and static at block scope, and would not permit the situation used in the example that I presented. Further, that it isn't clear the current compiler is in sync. with the proposed specification, and that is probably a higher priority issue. (Maybe my quick reading of the spec. was wrong, and someone can correct my misunderstanding.)
