From: Gabriel D. R. <gd...@in...> - 2012-05-06 03:20:17
|
Including the mingw64 project about this. On Sat, May 5, 2012 at 5:59 PM, Jonathan Wakely <jwa...@gm...> 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.) |