[Bug libstdc++/12855] Thread safety problems in ios_base::Init
rittle at latour dot rsch dot comm dot mot dot com
gcc-bugzilla@gcc.gnu.org
Tue Nov 11 08:17:00 GMT 2003
------- Additional Comments From rittle at latour dot rsch dot comm dot mot dot com 2003-11-11 08:16 -------
Subject: Re: Thread safety problems in ios_base::Init
>> std::ios_base::Init should never be used outside global objects.
> What about logging? Consider:
>static Foo foo;
[...]
>Foo::Foo()
>{
> std::ios_base::Init init;
> std::clog << "Foo constructed\n";
>}
>
>Foo::~Foo()
>{
> std::ios_base::Init init;
> std::clog << "Foo destroyed\n";
>}
On what non-hypothetical system does this code, precisely as shown,
fail to work in threaded cases?
Consider precisely when Foo::Foo or Foo::~Foo may run. Notice, they
don't run at random, non-predictable points.
Consider precisely which threads of control they may run upon. For
the case of libstdc++.so and any additional C++ shared libraries
linked against a program image, the only possible thread is the main
thread of control (thus, there is no multi-threading issue).
Consider footnote 265 on page 602 of 14882 which strongly implies
that it is a misuse for users to insert:
std::ios_base::Init init;
willy-nilly into any other methods and into constructors and
destructors which are not used to manage global objects (Stroustrup
offers stronger words about this). I hereby grant that footnotes are
not part of the standard. I also observe that our library has its own
definition of thread safety which again is not part of the standard.
BTW, I might buy the more complex case posted where dlopen was used...
Checking... Humm, on FreeBSD4 (in dlopen code inside the ELF RT
loader):
/* Call the init functions with no locks held. */
wlock_release();
objlist_call_init(&initlist);
wlock_acquire();
A patch for this issue would have to come at a point when we can break
the ABI since I don't think it will be safe to mix code. I'm still a
tad skeptical that this corner is a correct thing to "fix" (i.e. do
people really create C++ systems which allow any random thread to call
dlopen?). Oh well, opinions based on this analysis?
Regards,
Loren
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12855
More information about the Gcc-bugs
mailing list