>> To access thread-specific data using pthreads, you first need to take a lock >> and call pthread_key_create(). Since the whole point of thread-specific data >> is to avoid taking a lock, the API is useless. > > The normal way to do it is to use pthread_once to create the key, which does > not in general take a lock. (That or use an out-of-band prior initializer, > but that wouldn't work for malloc).
Most implementations of pthread_once use a spinlock, or some moral equivalent. Fundamentally, there’s no memory-safe way to implement concurrent one-time execution of arbitrary side effects without a spinlock. That’s why requiring concurrent one-time execution of arbitrary side effects in order to access thread-specific memory is broken API. > C++11 also introduces the thread_local keyword which is likely more readily > optimizable than function-call-based APIs where supported. thread_local might be a reasonable option, if a platform achieves all the other requirements for fast malloc. It’s still too slow, but at least it isn’t slow by definition, and it doesn’t pollute the rest of the code too badly. Geoff _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
