Thanks Liu, Very clear. Much appreciated! ----- Original Message ----- From: "Liu Hao" <[email protected]> To: "Maarten Verhage" <[email protected]>; <[email protected]> Sent: Tuesday, December 18, 2018 03:23 Subject: Re: [Mingw-w64-public] win32 threads
>在 2018/12/18 4:17, Maarten Verhage 写道: >> It's clear to me that although the files thread and mutex exist in the >> win32 >> builds it is not possible to use C++11 thread functionality in these >> builds. >> It seems to me that the variants like posix-seh, win32-seh, win32-sjlj >> primary deal with how mingw64 and/or gcc are working internally than what >> it >> provides to the programming environment. > > The thread model controls how GCC libraries (technically libgcc, > libstdc++, etc.) have been compiled and how GCC will make use of these > libraries. > > For example, the posix thread model emulates thread-local storage (for > `__thread` etc.) using `pthread_getspecific()` and > `pthread_setspecific()`, while the win32 thread model makes use of > `TlsGetValue()` and `TlsSetValue()`. Depending on the implementation the > win32 model is usually more efficient, but also suffers from some > limitations. > >> I also discovered that I am able to >> write a little program using pthreads even in the win32-seh variant. Then >> I >> just link with -l:libwinpthread.a and the program does what I expected. >> using the command "llvm-readobj -coff-imports test.exe" I learned that it >> used functions like _beginthreadex of msvcrt.dll. I also tested when >> linking >> with -l:libwinpthread.dll.a and I think libwinpthread-1.dll in its turn >> uses >> the same thread functionality of msvcrt.dll right? >> > > Yes. It is safe, as long as you don't mix use of these sets of APIs. As > a counterexample, calling `pthread_setspecific()` inside a thread which > was created using `_beginthreadex()` is considered inappropriate. > >> This goes a bit over my head. Are you talking about how mingw64 itself or >> gcc is doing it's job? > > Mostly the work is done inside GCC. In case of the win32 thread model, > Windows has no destructor callback for explicit TLS, whose indices are > allocated using `TlsAlloc()`. So mingw-w64 provides support for it. > >> What I meant with my question as to what it offers is >> from the perspective of doing software development for windows using >> various >> mingw64 build variants. As you have all this knowledge as you've shown >> above. Would you be willing to connect the dots of these pieces of >> knowledge >> to present something that would assist in the decision making for a >> software >> developers viewpoint to which build variant to use like: win32-seh, >> win32-sjlj, posix-seh? For example do any of these builds have an >> influence >> of the threading used in the executables build with mingw64? And >> concerning >> the stability and performance of mingw64 library itself and the gcc that >> is >> included, what for effect has the decision of the build variant on these >> topics? > > About thread models: > > 1. The `posix` thread model is required if you want to use > `std::thread`, `std::mutex` etc. > 2. The `posix` thread model is _extremely_ slow if there is little > contention. [*] > 3. There is a bug in winpthreads that calling `pthread_cond_signal()` > without having the corresponding mutex locked could result in > deadlocks. [+] > 4. The `win32` thread model is considered the opposite: fast and too > simple to provide C++11 thread support. > > [*] > https://github.com/lhmouse/mcfgthread/wiki/Benchmarking#test-results-of-x64 > [+] https://sourceforge.net/p/mingw-w64/bugs/774/ > > > About exception models: > > Just pick SEH where possible. It has been proven to be quite stable and > efficient because in absence of exceptions there is ZERO cost on normal > control flow, unlike SJLJ. As for x86 where SEH is unavailable, DWARF is > more efficient but suffers from binary incompatibility with code > compiled without exceptions (e.g. from C source) or compiled with a > different compiler (e.g. MSVC). > >> >> I would be sorry it this is somewhere easily found as documentation. I do >> realize this last one might be a big question. I would really appriciate >> if >> you are willing to clear this up for me and maybe for other people too. >> > > Don't mention it. :> > >> Best regards, >> Maarten Verhage >> > > > -- > Best regards, > LH_Mouse > _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
