Hello Jonathan! On Wed, May 9, 2012 at 7:06 PM, Jonathan Wakely <[email protected]> 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 ------------------------------------------------------------------------------ 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
