在 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
