[Mingw-w64-public] Thoughts on supporting the C++11 thread library on Windows

[K. Frank]

Hello Ruben and Gabriel!

On Sun, May 6, 2012 at 5:15 AM, Ruben Van Boxem
<vanboxem.ruben@gmail.com> wrote:
> 2012/5/6 Gabriel Dos Reis <gdr@integrable-solutions.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 ...
>> > ...
>> > 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:
> http://sourceforge.net/mailarchive/message.php?msg_id=26417059
> 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
issues.

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

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
like?

> I hope this helps!
>
> Ruben

Cheers!

> 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):
> http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/rubenvb/old/
> 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.

Best, K.F.