And don't forget that --enable-threads=win32 also enables emulated TLS, which is completely unnecessary if we have some kind of TLS support.
Because pthread_key_create() requires a destructor, TLS must still be emulated on x86 because there is no native support. The fiber local storage (FLS) APIs require the god damned __stdcall calling convention and are impossible to be made any use of. On x64 __stdcall has no effect and FLS APIs can be used to implement TLS functions. I tend to make a copy of the POSIX thread model and make some modification of it. ------------------ Best regards, lh_mouse 2016-04-14 ------------------------------------------------------------- 发件人：Dongsheng Song <[email protected]> 发送日期：2016-04-14 11:02 收件人：lh_mouse 抄送：Torvald Riegel,gcc,mingw-w64-public 主题：Re: Re: Adding a new thread model to GCC Currently, --enable-threads=win32 map to gthr-win32.{h|c}, could we map --enable-threads=win32-vista --enable-threads=win32-win7 // Windows 7 and Windows Server 2008 R2 --enable-threads=win32-win8 // Windows 8 and Windows Server 2012 --enable-threads=win32-win8.1 // Windows 8.1 and Windows Server 2012 R2 --enable-threads=win32-win10 // Windows 10 and Windows Server 2016 to gthr-windows.{h|c} with the corresponding _WIN32_WINNT macros ? Regards, Dongsheng On Thu, Apr 14, 2016 at 10:24 AM, lh_mouse <[email protected]> wrote: > Yes I learnt those *ByAddress* functions a few months ago and was shocked > that Microsoft had plagiarized futex from Linux. > As you have pointed out already, those APIs are only available on Windows 8 > and later. > > If we need fuex semantics on Windows 7 and earlier, we must simulate it. > However, since futexes and keyed events work differently, simulation of > futexes using keyed events would: > 0) require a lot of work, and > 1) suffer from performance penalty just like if we simulate keyed events on > Windows 2000. > > The major difference is that, the FUTEX_WAIT syscall is an atomic > compare-and-sleep operation, while the NtWaitForKeyedEvent syscall provides > no comparison. > Instead, the NtReleasedKeyedEvent syscall blocks the current thread until one > thread is woken up, while FUTEX_WAKE does nothing and returns immediately. > > So here is my condition: in no event shall portability harm either efficiency > or maintainability. > Linux and Windows work differently. I consider it 'harmful' to make one look > like the other. > > > ------------------ > Best regards, > lh_mouse > 2016-04-14 > > ------------------------------------------------------------- > 发件人：Torvald Riegel <[email protected]> > 发送日期：2016-04-14 01:40 > 收件人：lh_mouse > 抄送：gcc,mingw-w64-public > 主题：Re: Adding a new thread model to GCC > > On Wed, 2016-04-13 at 17:17 +0800, 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/ > > Have you looked at WaitOnAddress and WakeByAddressSingle / > WakeByAddressAll too? AFAIK this is new in Windows 8, and seems similar > to futexes. > > I think it might be better to get a std::synchronic (or similar) > implementation into GCC, and then use these to implement at least the > mutexes: > https://github.com/ogiroux/synchronic/blob/master/include/synchronic > > One benefit would be that we then have one place where we have optimized > spinning/blocking in libstdc++ on Windows, and less platform-specific > code. > > > ------------------------------------------------------------------------------ Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
