Thanks for your reply. :> However I am still having problems building GCC. (Yesterday stage 1 was ok, but during stage 2 autoconf just failed to find any standard headers. I am still struggling with it.) Once I build gcc successfully I will have a look at that configure.ac. Wish me luck. (btw this could be one or two days later. :<)
------------------ Best regards, lh_mouse 2016-04-13 ------------------------------------------------------------- 发件人：Jonathan Wakely <jwakely....@gmail.com> 发送日期：2016-04-13 18:30 收件人：lh_mouse 抄送：gcc,mingw-w64-public 主题：Re: Adding a new thread model to GCC On 13 April 2016 at 10:17, lh_mouse wrote: > Hi all, > > The 'win32' thread model of gcc has been there since long long ago, being > compatible with very old Windows versions, also having a number of drawbacks: > 0) its implementation is very inefficient, and > 1) its mutexes and condition variables require dynamic initialization and > are unusable in C++11 as std::mutex requires a `constexpr` constructor, and > 2) allocating a number of rarely used mutexes or condition variables would > eventually make the system run out of kernel objects. > > As a solution for 1) and 2), Microsoft introduced keyed events, details of > which can be found here: > http://joeduffyblog.com/2006/11/28/windows-keyed-events-critical-sections-and-new-vista-synchronization-features/ > > In one word: the Windows SRWLOCK and CONDITION_VARIABLE have been introduced > since Vista and are working well without any dynamic initialization, just > like FUTEX. > But there are still some major drawbacks: > 0) the SRWLOCK can be used as an exclusive mutex but it does not have an > equivalent function to pthread_mutex_timedwait, and Some of our supported targets don't support pthread_mutex_timedwait either (at least Mac OS X and HP-UX) so we have code in libstdc++ to support mutexes but not timed mutexes. That might also work for your new model. > 1) the CONDITION_VARIABLE can only be used with SRWLOCK and > CRITICAL_SECTION and no user-defined mutexes can be supportd. That's OK, std::condition_variable only needs to work with std::mutex, and then std::condition_variable_any (which works with user-defined mutexes) only requires std::mutex and std::condition_variable. The code to use user-defined mutexes is portable C++11, so doesn't need any platform-specific code. > As a solution, I come up with my own library: > https://github.com/lhmouse/mcfgthread > With 4 threads contending my mutex implementation turns to be 10 times faster > than the gthr-win32 implementation on my Xeon E3-1230 v3 processor. > I have also done some research on gthr.h and successfully created a wrapper > for __gthread_* functhins, which can be found in mcfgthread/src/env/gthread.h. Great! I haven't looked at the code, but I've been hoping someone would do something like this to improve the std::mutex and std::condition_variable implementations for modern Windows systems. > I am currently looking for ways to integrate this library into gcc as a new > thread model, let's say 'nt6' for example, so GCC can be configured with > --enable-threads=nt6. > But there is so little documentation about that. If someone know how to add a > new thread model in GCC, I would appreciate that. See line 1589 in gcc/configure.ac, where the allowed thread models are defined. Your gthreads wrapper header should be added as libgcc/config/i386/gthr-nt6.h and you might also need some changes to libgcc/configure.ac (see how it handles the existing gthr-win32.h model). You will need to use autoconf to regenerate the configure files after editing the configure.ac files (or for now you can just edit the configure files by hand, but eventually changes must go into the configure.ac files). I can probably help with that, although I can't build or test anything on Windows. Once you've added the new thread model as a gthr-xxx.h file in libgcc there will also be some work needed in libstdc++ to detect and correctly use the new model (e.g. to detect that the timedwait functions are not supported, so that timed mutexes will be disabled). We might want to discuss that latter part on the libstdc++ list.
