mcfgthread isn't a pthread implementation. Roughly, gthread is a subset of
pthread.
The gthread interfaces are defined in , 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(static_cast(-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 . 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 .
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
发送日期：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 .
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.
