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