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

["K. Frank" <kfrank29 dot c at gmail dot com>]

Hello Jonathan!

On Wed, May 9, 2012 at 7:06 PM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> On 9 May 2012 20:06, K. Frank wrote:
>> However, as noted in my previous post, I have happily done some
>> (limited) windows-api threading programming with Ruben's build
>> (and also did the windows-api threading programming necessary
>> to implement <thread>),

That's my fault for the confusion; I misspoke.

The --enable-threads=posix build of Ruben's that I referenced:

   gcc version 4.7.0 20110829 (experimental) (GCC)

is Ruben's <thread>-enabled 4.7.0 mingw-w64 build.

This is not the build upon which I built my threading implementation.

Instead I built my thread implementations on the following two
builds:

   a mingw build:
   gcc version 4.5.0 (GCC)

and

   a mingw-w64 build:
   gcc version 4.5.2 20101002 (prerelease) [svn/rev.164902 - mingw-w64/oz] (GCC)
   (If I remember correctly, this is a "sezero" build.)

Neither of these shows --enable-threads of any flavor (in gcc -v), but both
show "Thread model: win32" in the gcc -v output.

Sorry for the confusion.

On top of both of these builds I implemented my native win32-based
<thread>.  Note, in spite of "Thread model: win32" showing up in
gcc -v, I'm pretty sure that _GLIBCXX_HAS_GTHREADS was not
defined when these builds were built.

Separately I tweaked both of these builds to get <thread> working
by hooking them up to pthreads-w32 and pthreads-w64, respectively.
(Note, pthreads-w64 is not the winpthreads implementation that
Kai provided later, and is used by Ruben's <thread>-enabled build.
Rather, I would guess it's a tweak of pthreads-w32 built for 64-bit
windows.)

> If you use GCC built with --enable-threads=posix then you shouldn't
> need to implement <thread>, it should be provided.

No, this is not strictly true.  Prior to Kai's winpthread implementation
and Ruben's <thread>-enabled build (or the tweaks I made to get
<thread> working), building a windows version of gcc with
--enable-threads=posix won't, in and of itself, give you a working
<thread>.  One reason, among others, is that the posix version of
gcc's <thread> relies on the pthreads thread handle being a primitive
integral type.  This is not required by the posix standard, but is how
unix / linux pthreads has historically been implemented.  However,
pthreads-w32 uses (a pointer to) a struct as its thread handle,

So you either need a little tweak to accommodate this handle
difference, or follow Kai's approach of providing a windows version
of pthreads that uses an integral thread handle (winpthreads).

> In any case, as you're not using the win32 thread model you shouldn't
> are about my proposals and you're just derailing the topic ;-)

Sorry, that wasn't my intent.

I had thought you were discussing two parallel proposals:  First,
adding additional functionality and some support for <thread> to
the win32 implementation (gthr-win32.h, etc.); and second to
consider building a new, native (non gthr-win32.h, non gthr-posix.h)
<thread> implementation for gcc's <thread> on windows.

My main purpose was to share my experience doing the latter,
but I did make some comments about possible limitations of
doing the former.

I apologize if I may have confused the discussion by not being
familiar with the gcc's community use of "win32" in the term "win32
threading model."  In the windows world "win32" generally has the
connotation of the native windows api, and it didn't ring a bell with
me that it might refer to a windows-focused (partial) implementation
of the "gthreads" threading api (as in "_GLIBCXX_HAS_GTHREADS",
etc.).

>> all, I guess, with a gcc build built using
>> --enable-threads=posix, so what then does --enable-threads=win32
>> actually do?
>
> The code is all open source, feel free to read it.

Yes, of course, as a last resort.  But it's generally not my first choice.
(By way of analogy, I find it more practical to read the c++11 standard
for <thread>, or ask questions in the c++ news group, rather than read
the gcc source code for <thread>.)

> --enable-threads=win32 tells GCC to use the gthr-win32.h header to
> implement the gthreads abstraction API. ?Gthreads provides a
> pthreads-like API which libstdc++ (and libobjc and other bits of GCC)
> use for threading facilities. ?WIth --enable-threads=posix GCC uses
> the gthr-posix.h file which provides an implementation of gthreads
> based on pthreads (which is a one-to-one mapping.) With
> --enable-threads=win32 GCC uses the gthr-win32.h file which provides
> an implementation based on Windows primitives, which as I said several
> days ago means that the __gthread_mutex_t type is implemented as
> semaphores.

Yes, thank you.  This is coming back to me now, and I'm now clear on
what --enable-threads=win32 means and does.

> ...
> My original email, which I now seem to be repeating over and over,
> suggests changes to gthr-win32.h to allow std::mutex and C++11 other
> types to be defined in terms of the Windows primitives currently used
> in gthr-win32.h
>
> That gthr-win32.h header already exists, and already defines
> __gthread_mutex_t in terms of a semaphore, and it's too late to change
> that. ?So maybe if you re-read my original mail now it will make more
> sense.

Yes, thank you.  I follow what you're saying now and how gthr-win32.h
fits into everything.

In fact, in my native <thread> implementation I modified neither
gthr-win32.h nor gthr-posix.h, but wrote a new gthr-expr.h (and
some associated helper code).

> I proposed extending gthr-win32.h to allow std::thread and
> std::mutex to be provided WITHOUT CHANGING THE EXISTING IMPLEMENTATION
> OF gthr-win32.h, which would not allow native condition variables to
> be used because std::mutex is based on a semaphore and changing
> gthr-win32.h to not use a semaphore would not be backwards compatible
> and so is not an option.

Yes, of course.  If folks are using gthr-win32.h, we shouldn't break it
for them.

> In order to solve that problem I proposed a completely new gthreads
> implementation, for argument's sake gthr-win64.h, which being
> completely new could implement std::mutex differently, e.g. as a
> critical section, and std::condition_variable as a Windows condition
> variable,

Yes, this is what I did with my native "gthr-expr.h" <thread> implementation.

> As you are using gthr-posix.h you shouldn't need to care, you should
> already have std::mutex, std::thread, std::condition_variable etc.

Yes, now that Ruben has provided <thread>-enabled build (that indeed
was built with --enable-threads=posix), I do have std::thread, etc.
And this is the version of gcc I use for my day-to-day work.

But prior to Ruben's build (or when I want to play around with a native,
rather than a pthreads-based implementation) I used my own patched
version of one of Ozkan's builds (and also a 32-bit mingw build) to do
my windows <thread> programming, as that was my only option.

>
> So now I hope everyone's on the same page, but I don't actually think
> this thread has anything new since my original email on this subject
> four days ago ?:-\

Yes, thank you very much.


K. Frank