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

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

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