------- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20099
