[Bug c++/20099] -pthreads should imply -fno-threadsafe-statics

[davids at webmaster dot com]

------- Additional Comments From davids at webmaster dot com  2005-02-24 22:22 -------

> They are non-portable no matter how static initializers are done:
> C++ doesn't include threads and POSIX doesn't include C++.

That's a bogus argument. There are no conflicts between the two standards.

> Taking portability aside (as they are already non-portable), this is
> a wonderful quote when taken out of context. Yeah, if an option makes
> more code working and its negation makes more code break, let's make
> the breaking variant the default :-)

In any context, I stand by this quote. Code that does not conform to the
standards it requests during compilation should break. Compatability options
that make code work are fine, they just should not be on by default, especially
when they have a performance cost. Broken code should break.

> For me static locals in C++ are the equivalent of pthread_once in C/POSIX.
> A hypothetical C++/POSIX should make them MT-safe.

They are MT-safe, provided you lock shared data that may be accessed
concurrently. POSIX never permits you to modify shared data in one thread
when it may be accessed by another without a lock.

By your definition of MT-safe, almost no function is MT-safe. Is 'strchr'
MT-safe if you call it on a string while another function might modify that
string? No, so lets put automatic locks around 'strchr' and any function that
might modify a string.

A function is MT-safe if it does the same thing in an MT context that it does in
a UT context, provided the caller uses locks to prevent access to data in one
thread while another thread might access it. Static initialization is already MT
safe and these locks do not make it more so.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20099