Subj : Re: Can C++ local static objects be made thread safe? To : comp.programming.threads From : David Schwartz Date : Tue Feb 15 2005 08:52 pm "Alexander Terekhov" wrote in message news:42125628.CA329721@web.de... > David Schwartz wrote: >> Another implementation does the magic in the page mapping. Each >> thread >> gets the same address for the thread local variable, but a different page >> is >> mapped into that address in each thread. > That would preclude sharing and brake POSIX and C/C++ process/ > program object model with shareable objects and unique per-object > addresses (within a process). Thread-local objects are not supposed to be shared. As for it breaking POSIX, POSIX doesn't say what the __thread specifier should do, so nothing it could do would violate POSIX. It could cause an instant, unconditional crash, and POSIX would not be violated. > __thread storage duration is nothing but syntactical sugar for > accesses via pthread_getspecific() with "statically intialized" keys > and (GCC aside for a moment) object ctors and dtors thrown into the > mix. That may be one way to implement it, but as far as I know, no standard requires it. > The mappings (key/value bindings) can be held in per-thread "MMU > state" (see POSIX Rationale), but associated objects must have > unique addresses within a process and must be accessible from > other threads. > > Otherwise it's totally brain-dead. It's a lot faster, assuming the platform can do it, to keep the addresses the same and make it all work with page mapping magic. Accesses to thread-specific data are often very slow because of the overhead of figuring out which thread is running and finding the correct address. Mapping magic is faster where the platform can support it without an undue penalty on a context switch. The __thread extension is supported by many compilers and runtimes, not just GCC, and I can find no standard that mandates it work any particular way. DS .