On 7 May 2012 18:28, K. Frank wrote: > Hello Gabriel (and Ruben)! > > By the way, I'm the guy Ruben mentioned in his subsequent post. > > On Sat, May 5, 2012 at 11:20 PM, Gabriel Dos Reis > <[email protected]> wrote: >> Including the mingw64 project about this. >> >> On Sat, May 5, 2012 at 5:59 PM, Jonathan Wakely <[email protected]> >> wrote: >>> For GCC 4.7 I enabled most of <thread> (without timed mutexes) on Mac >>> OS X by making the _GLIBCXX_HAS_GTHREADS macro more fine-grained. I >>> think we could quite easily do the same again for the win32 thread >>> model (defined in gthr-win32.h) so that <thread> and <mutex> are >>> available (including timed mutexes), but without <condition_variable> >>> and <future>. > > Just my opinion: One could make the macro more fine-grained, but I > really wouldn't want to do this. If I'm using <thread> I'm using c++11, > so I like to think I'm in the "modern world." I think (in the modern world) > that condition variables are a core part of threading, so I'd find is a > significant limitation if my c++11 implementation didn't have them.
Well currently you get none of the thread support when GCC is built with --enable-threads=win32. IMHO that's an even more significant limitation than no <condition_variable> > (Also, I think that once you have the threading primitives (<thread>, > <mutex>, and <condition_variable>), you get <future> "for free" in the > sense that it's written on top of the primitives, and you don't need any > further os-specific support.) Right. >>> It's harder to support <condition_variable> because Windows didn't >>> provide condition variables until Vista, and even then they interact >>> with a CRITICAL_SECTION and gthr-win32.h defines mutexes in terms of a >>> semaphore not a critical section. > > Even leaving condition variables aside, I really don't think you want to > implement mutexes in terms of windows semaphores (or windows mutexes) > (unless your primary goal is to support older (pre-xp?) versions of windows.) Too late. That's how they're implemented when GCC is built with --enable-threads=win32 > I believe (speaking from memory) that I built a trial implementation of > <thread> > using windows mutexes and that it was much slower than using windows > critical sections. I think both creation and locking were slower, but I don't > remember the details. This is reasonable, because windows mutexes (and > semaphores) are heavier-weight objects -- they provide cross-process > synchronization, not just intra-process, cross-thread synchronization. > > And, as you mentioned, if you want to support condition variables (in terms > of windows condition variables), you need to base your mutexes on windows > critical sections. > >>> Douglas Schmidt describes an >>> implementation of condition variables at >>> http://www.cs.wustl.edu/~schmidt/win32-cv-1.html but that also >>> requires mutexes to be critical sections - maybe that could be adapted >>> to use the gthr-win32.h semaphore-based definition of >>> __gthread_mutex_t, I haven't looked into it in detail. My suggestion >>> would be to support <thread> and <mutex> but not <condition_variable> >>> (or <future> because our implementation uses a >>> std::condition_variable.) > > My personal feeling is that a version of <thread> that is complete > (i.e., supports condition variables and futures), but requires windows > vista or later is a fine way to go. > > Certainly given an either-or choice of an incomplete <thread> that > works pre-vista, or a complete <thread> that requires vista or later, > I would certainly vote for the complete <thread> and forgo pre-vista > support. > >>> I have some untested implementations of >>> __gthread_create, __gthread_join etc. if anyone wants to work on >>> implementing that suggestion. I don't have a Windows machine or >>> enough free time to do that myself in the near future. >>> >>> As a second idea, supporting the full C++11 thread library could be >>> done by creating a new thread model to be used instead of win32, which >>> would only be supported on Vista or later and would use Windows >>> critical sections for std::mutex and Windows condition variables for >>> std::condition_variable. > > I've done this, and it seems to work fine. I would recommend it. > > (I'm not sure what you mean by "a new thread model to be used instead > of win32." I mean instead of GCC's win32 thread model that you get by building with --enable-thread=win32 That existing thread model uses semaphores. My first suggestion is to improve that one in limited ways, retaining backwards compatibility but adding <thread> and <mutex> which AFAIK don't currently work. My second suggestion is to write a replacement (call it --enable-threads=win64 for the sake of argument) which would use critical sections and support <thread>, <mutex>, <ondition_variable> and <future>. The suggestions are independent of each other. > The way I look at it I used win32, i.e., I implemented <thread> > on top of the vista-and-later version of win32.) > >>> Critical sections don't support a timed >>> wait, so that thread model would be similar to the Mac OS X support >>> and omit timed mutexes. > > I had to write some extra code to get timed mutexes to work. I used > windows critical sections (just as for untimed mutexes), but spawned > a helper thread that blocked on the critical section, and had the original > thread use a timed windows WaitForSingleObject to wait (with a > timeout) for the helper thread. Spawning a new thread to block on a mutex seems over the top, but if it works it works. >>> That could easily be solved by implementing >>> std::timed_mutex as a Windows mutex instead of a critical section, > > Again, I wouldn't recommend using windows mutexes as you would > lose condition variables. No you wouldn't. std::condition_variable only works with std::mutex (which we agree should use a critical section), so it's irrelevant how std::timed_mutex is implemented. If you want to use a condition variable with a std:timed_mutex then you have to use std::condition_variable_any and that internally uses a std::mutex, so can internally use native OS condition varaibles. > Also, as I mentioned above, they are much > more expensive than critical sections. > >>> but >>> that would be difficult in the current Gthreads design because it >>> follows POSIX and assumes that a timed mutex is exactly the same type >>> as a non-timed mutex and you just use a different function to wait. >>> We should consider adding a __gthread_timed_mutex type which can be >>> different to __gthread_mutex_t, but would be the same type on POSIX >>> platforms that support the Timeouts option and define >>> pthread_mutex_timedlock. Again, I have some sketches to make that >>> work but nothing concrete. >>> >>> 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.) > > I have a pretty complete mingw / mingw-w64 <thread> implementation > that uses win32 directly and doesn't rely on pthreads. I'd certainly be > happy to make it available, if people would find it useful. As noted, it > requires vista or later. (I've only tested in on 64-bit windows 7.) > > But I'm not sure that there is any problem that needs to be solved. > > For my own <thread> programming, I have been using "The Mighty > Ruben's Wacky Build" (TM) of mingw-w64 gcc 4.7.0 that has <thread> > implemented on top of winpthreads. It passes all of my (not particularly > complete) <thread> tests. Presumably it works pre vista. > > And although I don't care much about pthreads, as a practical matter > there is an awful lot of pthreads code out there so a mingw-w64 > offering that doesn't support pthreads would be a significant limitation. > Now that mingw-w64 has winpthreads, it's very little work to modify > the linux gcc <thread> implementation to work on windows. There isn't a linux <thread> implementation, there is a POSIX one, used by building GCC with --enable-threads=posix. I expect that already works on Windows, I'm only talking about --enable-threads=win32 > Plus, > you get the added benefit that you can more easily mix pthreads > code with c++11 <thread> code because they use the same > underlying threading implementation (if you care). > > Also, there are (as would be expected) some performance differences. > I ran some tests about half a year ago. A parallel_accumulate > "practical" multithreading test was modestly slower with the > winpthreads implementation of <thread> than with the native > implementation; a mutex-contention test was more that an order > of magnitude slower; and a condition-variable test was significantly > faster. > > Please let me know if you would like any follow-up information. > > > Happy Threading! > > > K. Frank Thanks for the mail, it confirms a lot of what I thought based on some basic research and zero experience of Windows threading :) ------------------------------------------------------------------------------ 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
