Hi Thomas! On Thu, Jun 26, 2014 at 11:55 AM, C. Thomas Stover <c...@thomasstover.com> wrote: > On Thu, 26 Jun 2014 09:12:30 +0200, Etienne Sandré-Chardonnal wrote: >> ... >> Will _GLIBCXX_HAS_GTHREADS work in these cases or is this mingw-only? >> ... > > The macro you reference made me curious. Gthreads (part of glib) written > in C, is a wrapper around pthreads or win32 depending on how it was > built. This allows for a mix of generic code that uses the wrappers and > back-end specific code wrapped in #ifdef for portability. > > While I am aware that C++ 11 introduced a threading abstraction in- > language, I am not aware of the details. Does it not internally wrap OS > thread APIs?
Whether c++11's std::thread wraps the OS threading api internally is an implementation detail. (One would expect that it wraps at least some of the lowest-level native threading and synchronization primitives.) g++'s std::thread, both on linux and windows (i.e., mingw-w64) is implemented in terms of gthreads, which is a light-weight pthreads wrapper (that is very pthreads-centric). On linux, it uses native pthreads; in the case of mingw-w64, it uses winpthreads, the mingw-w64 port of pthreads to windows. Kai can tell you more, but I believe that winpthreads uses native windows threads for its underlying threads, but implements its synchronization structures (mutexes, condition variables, &c.) in terms of low-level windows atomics, rather than in terms of the analogous windows synchronization structures. > Are you trying to also mix generic C++11 threading with os > specific threading sections, or just use the native os APIs? > > Pthreads on windows is yet another variation on a theme since it would > have to wrap the win32 threading api. Again, mingw-w64 implements std::thread in terms of (the mingw-w64 port of) pthreads. This wraps (as I believe) native windows threads, but reimplements most thread synchronization in terms of lower-level windows atomics. That is, it partially wraps the windows threading api, and partially reimplements equivalent functionality. > Even with that I believe there is > still a way to mix in some straight up win32 api code if so needed. I > would be interested in hearing the details form those who know. In general I wouldn't try this (except for fun), as you would be depending on implementation details, but I do believe that you could spawn a (mingw-w64) std::thread or pthread, and then synchronize it on, for example, a windows critical section (a type of windows mutex). This should work because (as I believe), the underlying thread is, in fact, a windows thread. But you would not, for example, be able to use a windows condition variable with a (mingw-w64) std::mutex or pthreads mutex, because (as I believe) winpthreads does not use the windows synchronization structures under the hood. Happy Hacking! K. Frank ------------------------------------------------------------------------------ Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft _______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
