Re: [Mingw-w64-public] Thoughts on supporting the C++11 thread library on Windows

[Jonathan Wakely <jwakely dot gcc at gmail dot com>]

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