[Bug libstdc++/12855] Thread safety problems in ios_base::Init

["rittle at latour dot rsch dot comm dot mot dot com" <gcc-bugzilla at gcc dot gnu dot org>]

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