On Wed, Nov 11, 2015 at 11:56 AM, Andrew Haley <a...@redhat.com> wrote:
> On 09/11/15 23:55, David Holmes wrote: > > On 9/11/2015 8:54 AM, David Holmes wrote: > > > > Just to keep my thinking straight on this, the problem only exists for > > threads that existed before the JVM was loaded. All threads allocated > > after that will have space for all the TLS variables allocated directly. > > So the problem scenario is: > > > > - external process with existing threads loads the JVM > > - existing thread is executing critical library function eg malloc, when > > it takes a process-directed signal. > > - JVM signal handler runs and accesses _thr_current which triggers > > dynamic TLS allocation > > Why not simply use pthread_* thread-local storage, but only in the > signal handler? That would avoid the (fairly unlikely) race > condition, at very little cost. Sure, we'd have to use > pthread_setspecific() when attaching a thread, but that's no big deal. > > This could work. So, initialize both the pthread TLS slot and the __thread variable on thread creation. We could name them Thread::current and Thread::current_safe or similar. However, we still do not know how big the performance advantage is in using __thread over pthread_getspecific(). May not even worth all the trouble of using __thread. Thomas > Andrew. >
