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
Hello Ruben and Gabriel!
On Sun, May 6, 2012 at 5:15 AM, Ruben Van Boxem
> 2012/5/6 Gabriel Dos Reis <firstname.lastname@example.org>
>> Including the mingw64 project about this.
>> On Sat, May 5, 2012 at 5:59 PM, Jonathan Wakely <email@example.com>
>> > For GCC 4.7 I enabled most of <thread> (without timed mutexes) on Mac ...
>> > ...
>> > 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.)
> There was already talk of and an implementation of vista+ threading stuff.
> See this discussion:
> I have added the author of this code to the CC list to be sure he picks this
> up. I cannot seem to locate any patches he ever sent to the list, but he
> claims he got everything working using the "new" win32 threading primitives.
This is mostly just a follow-up to my previous post, where I've tried
to summarize some of the windows native <thread> background and
> I think an alternative threading model (a new --enable-threads=...) is a bad
> idea: this would mean one needs to rebuild GCC twice, make it incompatible
> with the normal win32 threading, and essentially release two versions of
> every binary you want to release. Better would be an automatic fallback to
> handrolled alternatives or plain failures on XP and earlier for the new
As I said in my earlier post, I have no problem with not supporting pre-vista.
(But the value of pre-vista support is really up to the community.)
> Perhaps a fallback to a pthreads implementation could work, but that
> would make everything dependent on winpthreads (even C code, through
> libgcc), which is not that great of an idea.
How bad is it to introduce winpthreads as a dependency?
As I suggested in my earlier post, it seems like the winpthreads
implementation is a sound approach to <thread>. You want to
offer pthreads in any event and (as far as I can tell) the winpthreads
<thread> implementation is complete and works. What's not to
> I hope this helps!
> PS: I have GCC builds utilizing MinGW-w64's winpthreads library and GCC
> 4.7's --enable-threads=posix for Windows and AFAICT everything C++11
> threading-related is pretty functional. You can find them here (everything
> released after 2010-09 is built with the above posix threading, the 4.6
> versions with the above change backported from 4.7):
> There were reports about some problems with Boost (exceptions when there
> shouldn't be), definitive performance regression (in non-c++11 code) and the
> winpthreads dll being a dependency through the libgcc dll, even for C code,
> which is far from ideal, but expected in this setup.
And my P.S.: As I mentioned in my earlier post, I have been using Ruben's
<thread>-enabled build, and it passes all of my tests. So the approach of
sticking with the winpthreads implementation of <thread> and directing
any available manpower to fixing and/or improving it rather than to building
a separate implementation seems on the surface sensible.