Seongbae Park wrote: > That's the only platform I know of that doesn't require different > sequence. > Should we make the language rules such that > it's easy to implement on one platform but not on the others, > or should we make it such that it's easy to implement in almost > all platforms ?
The fact that one current generally available platform doesn't require the __thread attribute on the extern should be enough to at least question whether an *error* should be diagnosed. Also, consider that compiler can't check for consistency across separately linked files and the linker already will give an error if references to __thread local objects don't have thread lcoal relocations. > > Also, what is the benefit of allowing mismatch between > declaration and definition of __thread vs non __thread ? The extern does not mismatch, it simply doesn't provide the __thread attribution. The compiler can determine this and quietly upgrade the extern, if it chose to. In my view, all of this should be unnecessary, and should really be a linker and OS implementation issue, but it seems like it may be difficult getting a conensus on that. > It only makes reading the code more difficult > because it confuses everybody - you need to look at the definition > as well as the declaration to know whether you're dealing > with a thread local variable or not which is BAD. The example I gave had the global declaration and extern in the same source file, and there it looks pretty silly. Typically, however, one will have a .h file where the extern lives and a single source file where the __thread local variable is declared. And often, typically, the .h file might be handed off to another group as the API to be used when accessing the separately compiled implementation. In that scenario, the users of the .h file won't have the opportunity to check whether it agrees with the data object declaration anyway. So, the inconsistency will only be detected when the data object is declared, _if_ the programmer also #includes the header file with the extern declaration into the same file that declares the object. More to the point, I think it is rather too bad that the extern has to have the __thread attribute at all, and would have hoped that the linker and OS could have collaborted to make this transparent, in the same way that data can arranged in separately linked sections without impacting the way the external references are written. Thus, implementation is separated from interface. > ...proposed scheme snipped... Those weren't just proposals. Some systems already implement mechanisms like those mentioned (not proposed), and the IA64 is apparently one of those systems. > > The question to me is not whether it's doable, but whether it's > worth doing > - I see only downside and no upside of allowing mismatch. Given that on some systems, there is no need to have __thread on the extern at all, why should the compiler mandate it? If it does mandate consistency, then it should at least do so on a per platform, per compilation option basis. After all __thread isn't supported on all platforms or under certain compilation regimes -- thus the check for __thread support is made conditional upon the characteristics of the compilation target. I think the requirement to apply _thread to an extern should also be target specific. > If you're convinced that this is a really useful thing for a > particular platform, > why don't you create a new language extension flag that allows this, > and make it default on that platform ? Because it is the current implementation of __thread that is in opposition to the generally accepted practice of separating interface from implementation, and because some implementations (both present and future) do not require that the external reference be attributed with __thread.
