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). ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
