[Bug middle-end/26461] liveness of thread local references across function calls

[dwood at sybase dot com]

------- 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