------- Comment #8 from dwood at sybase dot com 2010-08-23 21:13 ------- I believe this is a bug or a serious oversite in understanding the need for support of >>>USER<<< thread local storage. There are two kinds of software threads; a) kernel threads(AKA LWP's on Solaris) scheduled by the OS; and b) user threads scheduled by the user and/or threading library. Databases such as Informix and Sybase both manage their own user threads(1 per client connection). These run on a small pool of "engines" which are either kernel threads or processes(No more than one per cpu core). The user threads do cooperative scheduling by calling their own yield implementation and they never yield in a critical section. These products and perhaps others are not little weird cases.
These user threads can migrate between kernel threads as load balancing occurs. Of course, this requires that the implementation of the user level thread context switch must save/restore USER TLS variables from/to the TLS areas of the kernel threads involved. If the model where M user threads are handled across N kernel threads is valid then the address of "USER" TLS variables can change across a context switch. We, Sybase, have run into the same problem on Solaris-Sparc and are evaluating whether gcc __thread on x86_64 will have the same problem. Of course, the database folks often hear from the OS folks the common reply like: Why are you doing this? Just trust the OS and leave it all to us. But for us we have to trust AIX, Linux, Solaris, HP-UX, Windows, etc. This is the same whether we are talking about using USER threads or the dreaded Linux O_DIRECT debate. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26461
