From: Jonathan W. <jwa...@gm...> - 2012-05-09 23:14:42
|
On 9 May 2012 20:49, Kai Tietz wrote: > > The issue about critical-sections and gthread (and also pthread) API > is, that not all locking-kinds can be modelled by it. The difference > on Windows for it is, that a critical section object provides > synchronization similar to that provided by a mutex object, except > that a critical section can be used *only* by the threads of a single > process. > (see http://msdn.microsoft.com/en-us/library/windows/desktop/ms682530%28v=vs.85%29.aspx > ). This makes it pretty useless for many classical scenarios. Since the C++ standard doesn't say anything about IPC, std::mutex only needs to work for a single process, so that's not necessarily a problem. Also, libstdc++ on POSIX uses a pthread_mutex_t that isn't necessarily safe for use in multiple processes, as it doesn't have the PTHREAD_PROCESS_SHARED attribute set (unless the OS sets it by default for all mutexes). It could be argued that a different type (let's call it interprocess_mutex) should be used for that case, which could be implemented as a Windows mutex (not critical section) on Windows and on POSIX would be a pthread_mutex_t with PTHREADS_PROCES_SHARED attribute (and where supported PTHREADS_MUTEX_ROBUST) That way std::mutex is more lightweight, using the fastest implementation available, but only supporting a single process and not paying for the overhead of interprocess support (you don't pay for what you don't use). |