This is the mail archive of the
mailing list for the GCC project.
Inherited thread-local variables
- From: Nadav Har'El <nyh at math dot technion dot ac dot il>
- To: gcc at gcc dot gnu dot org
- Cc: osv-dev at googlegroups dot com
- Date: Sun, 13 Jul 2014 15:34:24 +0300
- Subject: Inherited thread-local variables
- Authentication-results: sourceware.org; auth=none
- Hebrew-date: 15 Tammuz 5774
Hi, I'm trying to implement *inherited* thread-local C++ variables.
These are are per-thread values, like regular thread-local variables,
with one twist: the value in a new thread is copied from the value in
the parent thread, instead of being set to its default value.
Everything is working for me with except one thing: "__thread" refuses
to work on a class with a destructor, and I can't seem to disable this
check, even though I'm quite aware of what this would mean (that I'd need
to call the destructor manually).
Let me explain why I want to do this. My implementation works like this:
1. Maintain a list of all inherited-thread-local-variables.
2. An inherited-thread-local-variable is a regular __thread T var.
so "var" can be used just like any __thread variable.
3. When a new thread is created we loop over the above list, copying
each of the variables from the old thread to the new one (the
copy is done, of course, using type T's copy constructor or assignment).
4. When a thread is deleted, we (should) again iterate over the list,
running each variable's destructor.
All is working well except step #4 - __thread simply refuses to accept a
class T with a destructor :-(
One suggestion someone can give me is to switch from __thread to the C++11
thread_local. However, that would be unfortunate, and should be
unnecessary: thread_local has a performance penalty when used.
This penalty exists because the code doesn't know when it needs to construct
the variable so it needs to check every time. But in my "inherited"
variable case, I always construct the variable when the new thread
is being created. So there shouldn't be any need for the runtime
penalty. Moreover, just like I explicitly run a set of copy functions
when the thread is created, I can explicitly run a set of destructors when
the thread ends - I don't care that __thread fears that the destructor will
never be called. I promise it will ;-)
Is there some way to twist the compiler's arm to allow __thread on a class
that does have a destructor?
Alternatively, has anyone ever tried a different approach to
efficiently implementing inherited thread-local variables?
P.S. I'm doing this in the context of OSv (http://osv.io), a new
open-source operating system for virtual machines. OSv is written in C++11
and using all the latest and coolest features of gcc :-)
Nadav Har'El | Sunday, Jul 13 2014, 15 Tammuz 5774
Phone +972-523-790466, ICQ 13349191 |This '|' is not a pipe.