This is the mail archive of the
mailing list for the libstdc++ project.
Re: [Mingw-w64-public] Thoughts on supporting the C++11 thread library on Windows
On Wed, May 9, 2012 at 6:14 PM, Jonathan Wakely <email@example.com> wrote:
> 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
>> (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).
For the record, I agree with your proposal.
The intent of my forwarding your original message to mingw-64 was to
draw their attention since they have been doing work in this area for
some times and the likely compiler port maintainers are there.
I do hope your patience will pay off :-)