Hacker News Reader

Comment by matthewbauer | Hacker News Reader

My understanding is that while pthreads don't work, c++11 threads are supported.

If only that were so! At least up to gcc version 9.3 it does not work. I will try gcc 10 soonish but I don't have high hopes.

The whole reason I installed a cross compiler to Windows is so I could cross compile some search engine code I wrote that uses C++ threads. But if you have a copy of the header and run-time files from Visual Studio (there is a free edition of that now) you can actually use clang to cross compile for Windows from Linux just fine, including C++ threads.

It looks like you need to set --enable-threads=posix when building GCC.

gcc on Windows uses winpthreads for C++11 threads, which works just fine (it automatically links with libwinpthread)... I can basically use the same threading code for all platforms (except the stuff that is necessarily platform dependent and therefore not part of C++11). I should note that I use msys2. So I'm wondering what you are missing?

That being said, I often use my own STL like mutex class which wraps SRWLock on Window and pthtead_mutex_t on Linux/macOS.

The reason (for me) to use msys in the first place would be so I can create binaries that do not depend on obscure DLLs like winpthread. If depending on 3rd party DLLs was no problem, I could have used Cygwin.

Also, as I heard it, winpthread combines the warts of windows threads with the warts of pthreads, doing neither justice.

You can link both libstdc++ and libwinpthread statically if you want. Both libs come with msys2, so I wouldn't really call them obscure third-party DLLs... In practice, threading is not a problem at all with gcc on Windows. I agree, however, that libwinpthread is not the most efficient implementation (that's why I roll my own), but for most purposes it's good enough.

Reply on news.ycombinator.com