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

["davids at webmaster dot com" <gcc-bugzilla@gcc.gnu.org>]

------- Additional Comments From davids at webmaster dot com  2005-02-20 10:48 -------

There is certainly the eternal argument whether a class should implement its own
locks internally or whether the caller should implement them. The first case
simplifies calling at the expense of overhead when you don't need it. The second
makes callers have more knowledge of how the functions they're calling work, but
make possible optimizations in cases where the locks aren't needed, and only the
caller knows this.

POSIX made this decision. The POSIX memory visibility rules specifically require
a mutex to be held in cases where an object may be modified by another
concurrent thread. So POSIX code *must* already contain such mutexes. This
requirement in POSIX is as clear as anything can be. The rationale is that on
some platforms, locks may be very expensive, so requiring them implicitly was
carefully avoided. POSIX requires shared data to be explicitly locked by
application code when data might be modified in one thread and read in another
concurrently.

While the C++ standard doesn't say anything about threads, it says a lot about
how static objects are initialized. It specifies initialization on first use,
thus first use is a modification. Use that might be first use might be a
modification.

There is no other sensible reading of the POSIX standard. There is no other
sensible reading of the C++ standard.

The arguments presented are disingenous. They would equally well defend the
decision to initialize all static objects before calling 'main' in multithreaded
code. After all, C++ doesn't say anything about multithreaded code and POSIX
doesn't say anything about initializating C++ static objects. In fact, the
arguments would defend crashing on any multithreaded C++ code, which is
obviously not what anyone wants.

If there is going to be C++/POSIX code, the C++ standard and the POSIX standard
will have to be made to coexist. POSIX requires the application to figure out
when objects may be accessed concurrently, and does so for good reason. In a
non-POSIX context, it may make sense to have the compiler try to automatically
insert mutexes, but it definitely doesn't in the POSIX case.

The compiler should, by default, make the optimizations that the standards
permit. This is the way every other similar option has been implemented.


-- 


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