mcfgthread isn't a pthread implementation. Roughly, gthread is a subset of pthread. The gthread interfaces are defined in <gthr.h>, which should be part of libstdc++ headers installed.
The history of mcfgthread is a long story... Well, please bear with me. Once upon a time I was compiling libcxx with libwinpthread... well it failed because ISO C++ requires the default constructor of `std::mutex` to be `constexpr`. libwinpthread, however, defines `pthread_mutex_t` as `void *` and `PTHREAD_MUTEX_INITIALIZER` as `(void *)-1`, which violates the standard because it would need to involve a `reinterpret_cast` to work (note that `(void *)-1` is equivalent to `reinterpret_cast<void *>(static_cast<intptr_t>(-1))` ). clang++ is correct to reject the code. For whatever reason, GCC accepted the code. Then I asked in #mingw-w64 on OFTC why didn't its author (probably Kai, I am not sure) define `PTHREAD_MUTEX_INITIALIZER` as a plain `0`. Kai answered, the magical value `(void *)-1` existed to mark a mutex as 'to be initialized on first use'. So did `(void *)-3` to mark it as 'to be initialized as a recursive mutex on first use' etc. Then I started to look into its source code and found the implementation of winpthread very very problematic. The issues of winpthreads are: 0) It is very inefficient, probably due to Windows XP compatibility. 1) Its initializers violate the C++ standard, despite GCC's acceptance. 2) Its mutex and condition variable can't be trivially destructed unlike those on Linux. And a few more... Then I thought it was time to write a new thread library. But I didn't want to reinvent winpthread because it would be an overkill. Then the `win32` thread model of GCC came into my sight. > 'It is working despite lack of std::thread support, isn't it?' Then I forked MCFCRT for a clean room design of a thread library that would meet the minimum requirements of GCC with c++0x thread, more than the win32 thread model of course. It didn't take me long to discover <gthr.h>. Then I sent this mail to the GCC mailing list: https://gcc.gnu.org/ml/gcc/2016-04/msg00080.html (I appreciate Jonathan Wakely's kindly support.) The result was mcfgthread. 0) Its mutex is 10x times faster than the one in <gthr-win32.c>. 1) Its mutex, condition variable and once-initialization flag can be zero-initialized with `{ 0 }` in C and C++98, and just `{ }` since C++0x, conforming to the standard. 2) A mutex, condition variable or once-initialization flag has the same size of a pointer and allocates no kernel object or extra memory. They can be trivially destructed without resource leaks. 3) It enables GCC libraries to be built with full C++0x thread support. The drawbacks of mcfgthread: 0) It can't be linked statically without hacking the CRT. 1) It is not claimed to support Windows NT 5.x or below. That is, Windows XP and Windows Server 2003. Well... if we bear with it, we have at least an efficient and c++0x conforming thread implementation for GCC on MinGW targets. ------------------ Best regards, lh_mouse 2016-06-12 ------------------------------------------------------------- 发件人：Ruben Van Boxem <vanboxem.ru...@gmail.com> 发送日期：2016-06-12 15:48 收件人：lh mouse,gcc,mingw-w64-public 抄送： 主题：RE: [Mingw-w64-public] Contribute to GCC - the MCF thread model for MinGWtargets Hi! I do wonder how this compares with e.g. the MinGW-stdthread header only implementaion on github. As far as I remember, the author explicitly relicensed his code so it could be used for the same purpose. How dies it compare to your implementation? Since the ABI of the toolchain will be different when built against your intermediate library, what is the advantage over say, winpthreads or just providing a direct win32 implementation of gthreads in libgcc proper? It seems to me that instead of linking to mcfthreads, the right way forward would be to integrate this code into libgcc directly, no? Just me 2 cents in this… Ruben Van: lh mouse Verzonden: zondag 12 juni 2016 8:51 Aan: gcc; mingw-w64-public Onderwerp: [Mingw-w64-public] Contribute to GCC - the MCF thread model for MinGWtargets Hello GCC developers, I have implemented a gthread library for both the i686 and x86_64 MinGW targets, which supports all c++0x thread features required by <gthr.h>. This library is experimental and stil lrequires testing. However Kai suggested I donate it to the FSF so it could be merged into the GCC upstream. I am looking at this https://gcc.gnu.org/contribute.html , but here I have a few questions: 0) Legal Prerequisites In order to add a new thread model, a new library has to be introduced since on Windows TLS destructors can't be implemented without either hacking the CRT or using a shared library. The source code of the mcfgthread library can be found here: https://github.com/lhmouse/mcfgthread . It is essential to link against this library dynamically. All headers of this library are put into the public domain and the rest are licensed under the GNU LGPL. See MCFLicense.txt for details. Adding a new thread model requires modifying GCC source. The patch can be found here: https://github.com/lhmouse/MINGW-packages/blob/mcfgthread/mingw-w64-gcc-git/9000-gcc-6-branch-Added-mcf-thread-model-support-from-mcfgthread.patch Because it applies to GCC source, I would grant you GCC developers the right to do whatever you want with this patch, including re-licensing. Is this sufficient? 1) About 'Coding Standards': Most code is done in the mcfgthread library and I try to keep modification of GCC source as little as possible. Thus, do I still have to have regard for the GNU coding standard in the standalone library? I have my own coding style indeed. I will accept any of your suggestions for the patch to the GCC source, of course. 2) About 'Testing Patches': mcfgthread fails the following test: gcc/libstdc++-v3/testsuite/30_threads/recursive_mutex/unlock/1.cc This test tries to unlock an unlocked recursive_mutex. According to ISO C++ this is undefined behavior and it causes an assertion failure (thus abnormal termination) in mcfgthread. The source code of __gthread_recursive_mutex_unlock() function can be found here: https://github.com/lhmouse/mcfgthread/blob/master/src/env/gthread.h#L171 I suggest we drop this test. Any further discussion is welcome. -------------- Best regards, lh_mouse 2016-06-12 ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e _______________________________________________ Mingw-w64-public mailing list mingw-w64-pub...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
