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

qrczak at knm dot org dot pl gcc-bugzilla@gcc.gnu.org
Sun Feb 20 18:12:00 GMT 2005

------- Additional Comments From qrczak at knm dot org dot pl  2005-02-20 13:00 -------
> There is certainly the eternal argument whether a class should implement its own
> locks internally or whether the caller should implement them.

And my guideline is as follows: it should implement its own locks if it provides
a single global object, and it should leave locking to the callers if it
provides objects created dynamically.

The reasoning is that dynamically created objects are often used locally in one
thread, in which case locking would be unnecessary, while a singleton is always
accessible to all threads.

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

POSIX gave mechanisms for synchronization. In particular pthread_once can be
used to guard initialization, such that the object doesn't need an additional
mutex if it's not modified later. pthread_once provides the semantics
"initialize before first use (in a MT-safe way)".

Static locals in C++ are an equivalent to pthread_once in C/POSIX.



More information about the Gcc-bugs mailing list