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
On Wed, May 9, 2012 at 3:03 PM, Ruben Van Boxem
> 2012/5/9 Jonathan Wakely <firstname.lastname@example.org>
>> That's not an option. ?If there is to be a non-backwards-compatible
>> implementation then it must be a new thread model,
>> e.g.--enable-threads=win64 (yes, that name is wrong, it's just an
> Yes, a different implementation would need a different thread model, unless
> some form of startup code could detect OS version (or better, API
> availability) and set function pointers accordingly. This would be IMHO the
> best solution: new stuff if available, fallback to older (slower) stuff, and
> fail (runtime exception) in case of truly missing irreplacable features.
If you do this, does it solve the issue you mention below of having
"code built with GCC will depend on winpthreads through libgcc"?
Or is it still a problem because the code might still depend on
winpthreads, but the presence or absence of that dependency is
only determined at runtime in the startup code?
> Yes, <thread> and associated things work when I configure GCC to use posix
> threads (through the winpthreads layer).
And when I use Ruben's build that uses --enable-threads=posix,
I can get my native <thread> implementation working without
rebuilding gcc. (So I don't really understand what the practical
implications of --enable-threads=posix vs. --enable-threads=win32
> There are a couple of reasons not to have this as a final solution:
> 1) As Kai already mentioned, all/most code built with GCC will depend on
> winpthreads through libgcc. This is stupid, and in my eyes, bad.
> 2) All of GCC's threading stuff goes through the gthread api in libgcc.
> winpthreads is a compatibility layer, which admittedly works great, but
> really does have slower performance than a bare metal implementation.
With the exception of the fact that my test of Kai's condition-variable
implementation showed a significant performance increase. (Unless
I introduce an inefficiency in my native implementation. But my
native implementation is just a pretty simple wrapper for the underlying
windows condition variables.)