bug-glibc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

thread local storage: static class member does not work


From: Marshall, Simon
Subject: thread local storage: static class member does not work
Date: Wed, 21 Jan 2004 14:52:33 -0000

Hi, I'm reporting this bug here after being told that the bug lies with
glibc, not gcc (see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13668).

A static class member should be able to be thread local:

class foo {
  static __thread int i;
};
__thread int foo::i = 0;
foo bar;

If bar.i is used in the same file as where bar is instantiated, then
bar.i is indeed thread-local.  However, if bar.i is used in another
file, then it is not.  This appears to be a bug.

The attached test case contains 3 source files: __thread.hpp,
__thread.cpp defining foo(), __threadmain.cpp defining main().  Build
a.out using the supplied Makefile.

__thread.hpp declares 2 classes, class Encap and template wrapper Templ.
Both contain static thread-local members.
__threadmain.cpp instantiates 3 objects: one a thread-local POD, one of
Encap, one using Templ.  Its main() creates threads running function
foo().
__thread.cpp defines foo() that sets the POD and thread-local values of
the Encap instance and Templ instance to the thread id.  It outputs the
thread-local values and their addresses at the start of foo() and end of
foo().

In the test case, only the POD appears to be thread-local.  The Encap
instance and Templ instance are not.  The file a.1 shows that, as foo()
exits in the different threads, the thread-local values are incorrect.
Not surprising, as the address of each of the thread-local members of
Encap and Templ are the 
same.  This is a bug.

If the instantiations of Encap and Templ are moved from __threadmain.cpp
to __thread.cpp (where foo() is defined and the instances are used),
then all are thread-local.  File a.2 shows that the addresses of each of
the thread-local members of Encap and Templ are different, as I would
expect.  This is correct.

This is on rh9.
llama 200> gcc -v
Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/specs
Configured with: ../configure --enable-shared --enable-threads=posix
--with-
system-zlib --enable-__cxa_atexit
Thread model: posix
gcc version 3.3.2
llama 201> ld -v
GNU ld version 2.13.90.0.18 20030206
llama 202> as -v
GNU assembler version 2.13.90.0.18 (i386-redhat-linux) using BFD version

2.13.90.0.18 20030206
llama 203> uname -a
Linux llama 2.4.20-28.9smp #1 SMP Thu Dec 18 13:37:36 EST 2003 i686 i686
i386 
GNU/Linux

 <<tls-bug.tgz>> 

Attachment: tls-bug.tgz
Description: Binary data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]