Including the mingw64 project about this. On Sat, May 5, 2012 at 5:59 PM, Jonathan Wakely <[email protected]> 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.)
------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
