Re: Thoughts on supporting the C++11 thread library on Windows

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

Including the mingw64 project about this.

On Sat, May 5, 2012 at 5:59 PM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> For GCC 4.7 I enabled most of <thread> (without timed mutexes) on Mac
> OS X by making the _GLIBCXX_HAS_GTHREADS macro more fine-grained. ?I
> think we could quite easily do the same again for the win32 thread
> model (defined in gthr-win32.h) so that <thread> and <mutex> are
> available (including timed mutexes), but without <condition_variable>
> and <future>.
>
> It's harder to support <condition_variable> because Windows didn't
> provide condition variables until Vista, and even then they interact
> with a CRITICAL_SECTION and gthr-win32.h defines mutexes in terms of a
> semaphore not a critical section. ?Douglas Schmidt describes an
> implementation of condition variables at
> http://www.cs.wustl.edu/~schmidt/win32-cv-1.html but that also
> requires mutexes to be critical sections - maybe that could be adapted
> to use the gthr-win32.h semaphore-based definition of
> __gthread_mutex_t, I haven't looked into it in detail. ? My suggestion
> would be to support <thread> and <mutex> but not <condition_variable>
> (or <future> because our implementation uses a
> std::condition_variable.) ?I have some untested implementations of
> __gthread_create, __gthread_join etc. if anyone wants to work on
> implementing that suggestion. ?I don't have a Windows machine or
> enough free time to do that myself in the near future.
>
> As a second idea, supporting the full C++11 thread library could be
> done by creating a new thread model to be used instead of win32, which
> would only be supported on Vista or later and would use Windows
> critical sections for std::mutex and Windows ?condition variables for
> std::condition_variable. ?Critical sections don't support a timed
> wait, so that thread model would be similar to the Mac OS X support
> and omit timed mutexes. ?That could easily be solved by implementing
> std::timed_mutex as a Windows mutex instead of a critical section, but
> that would be difficult in the current Gthreads design because it
> follows POSIX and assumes that a timed mutex is exactly the same type
> as a non-timed mutex and you just use a different function to wait.
> We should consider adding a __gthread_timed_mutex type which can be
> different to __gthread_mutex_t, but would be the same type on POSIX
> platforms that support the Timeouts option and define
> pthread_mutex_timedlock. ? Again, I have some sketches to make that
> work but nothing concrete.
>
> If there are any Windows hackers out there who want to improve thread
> support on their platform please get in touch, I'll be happy to help
> and advise (although not for the next two weeks as I'm about to go on
> holiday.)