wątki mingw-w64: posix vs win32

130

Instaluję mingw-w64 w systemie Windows i są dwie opcje: wątki win32 i wątki posix. Wiem, jaka jest różnica między wątkami win32 i pthreads, ale nie rozumiem, jaka jest różnica między tymi dwiema opcjami. Wątpię, czy jeśli wybiorę wątki posix, uniemożliwi to wywoływanie funkcji WinAPI, takich jak CreateThread.

Wygląda na to, że ta opcja określa, które API wątków będzie używane przez jakiś program lub bibliotekę, ale przez co? Przez GCC, libstdc ++ czy coś innego?

Znalazłem to: Jaka jest różnica między thread_posixs i thread_win32 w porcie gcc w systemie Windows?

W skrócie, dla tej wersji mingw, wydanie thread-posix będzie używać API posix i pozwoli na użycie std :: thread, a wątki-win32 użyją API win32 i wyłączy część std :: thread standard.

Ok, jeśli wybiorę wątki win32, to std :: thread będzie niedostępne, ale wątki win32 będą nadal używane. Ale przez co?

Szymon
źródło
Używany przez aplikacje utworzone przy użyciu tego gcc.
devnull
@devnull, czy nie jest to określone przez interfejs API, którego będę używać? Jeśli wybiorę wersję MinGW pthreads, to co uniemożliwi mi używanie WinAPI do obsługi wątków?
Simon
gcc cię powstrzyma, a raczej: stanie się niestabilny
jiggunjer

Odpowiedzi:

125

GCC jest dostarczane z biblioteką wykonawczą kompilatora (libgcc), której używa (między innymi) do dostarczania niskopoziomowej abstrakcji systemu operacyjnego dla funkcji związanych z wielowątkowością w obsługiwanych językach. Najodpowiedniejszym przykładem jest libstdc ++ 's C ++ 11 <thread>, <mutex>oraz <future>, które nie posiadają pełną implementację gdy GCC jest zbudowany z gwintem wewnętrznym modelu Win32. MinGW-w64 zapewnia winpthreads (implementację pthreads będącą uzupełnieniem interfejsu API wielowątkowości Win32), do którego GCC może się następnie łączyć, aby włączyć wszystkie wymyślne funkcje.

Muszę podkreślić, tej opcji nie zabrania wam pisać żadnego kodu, który chcesz (nie ma absolutnie NIE wpływają na to, co można nazwać API w kodzie). Odzwierciedla tylko to, czego biblioteki wykonawcze GCC (libgcc / libstdc ++ / ...) używają ze względu na ich funkcjonalność. Zastrzeżenie przytoczone przez @James nie ma nic wspólnego z wewnętrznym modelem wątków GCC, ale raczej z implementacją CRT firmy Microsoft.

Podsumowując:

  • posix: włącz funkcje wielowątkowości C ++ 11 / C11. Sprawia, że ​​libgcc zależy od libwinpthreads, więc nawet jeśli nie wywołasz bezpośrednio API pthreads, będziesz dystrybuować bibliotekę DLL winpthreads. Nie ma nic złego w rozpowszechnianiu jeszcze jednej biblioteki DLL z aplikacją.
  • win32: Brak funkcji wielowątkowości w C ++ 11.

Nie mają również wpływu na kod użytkownika wywołujący interfejsy API Win32 lub API pthreads. Zawsze możesz użyć obu.

rubenvb
źródło
7
Zawsze możesz łączyć środowisko wykonawcze gcc i winpthreads statycznie, eliminując konieczność dołączania DLL.
Alexander Shishenko
3
Zajęło mi trochę czasu, aby znaleźć odpowiednią opcję w systemie Linux, więc w przypadku, gdy ktoś inny pomaga: Pakiet g++-mingw-w64-x86-64zawiera dwa pliki x86_64-w64-mingw32-g++-win32i x86_64-w64-mingw32-g++-posix, i x86_64-w64-mingw32-g++jest aliasem do jednego z nich; zobacz update-alternatives --display x86_64-w64-mingw32-g++.
stewbasic
Hmm, mówisz "... które nie mają pełnej implementacji, gdy GCC jest zbudowane z jego wewnętrznym modelem wątków Win32 .... MinGW-w64 dostarcza winpthreads (implementację pthreads na szczycie wielowątkowego API Win32), który GCC może następnie połącz, aby włączyć wszystkie fantazyjne funkcje ”. Więc jeśli wybiorę model win32, GCC może nadal włączyć wszystkie funkcje, ponieważ korzysta z winpthreads? Ale w podpunkcie poniżej piszesz „win32: brak funkcji wielowątkowości w C ++ 11”. Nie rozumiem. Czy „które GCC może wtedy połączyć się z ...” oznacza, że ​​jeśli nie wybiorę win32, będzie mógł wybrać ...?
Johannes Schaub - litb
@ JohannesSchaub-litb Cóż, nie. Magia konfiguracji GCC łączy wybór wewnętrznego modelu wątku z włączonymi funkcjami libstdc ++, ponieważ ta ostatnia jest zbudowana na podstawie wewnętrznego opakowania GCC „gthread” (które jest po prostu cienką abstrakcją wątku podobną do posixa. Brakuje podstawowych elementów funkcji C ++ 11) w tej warstwie, kiedy używasz --threads=win32. Tak długo, jak brakujące bity nie są zaimplementowane w GCC, musisz skonfigurować GCC z --threads=win32.
rubenvb
Czy mogę używać prekompilowanych bibliotek qt mingw, które używają -win32, z innymi bibliotekami używającymi -posix i używają obu bibliotek w tym samym programie?
Johannes Schaub - litb
16

Części środowiska wykonawczego GCC (w szczególności obsługa wyjątków) zależą od używanego modelu wątków. Tak więc, jeśli używasz wersji środowiska wykonawczego, które zostało zbudowane z wątkami POSIX, ale zdecydujesz się utworzyć wątki we własnym kodzie za pomocą interfejsów API Win32, prawdopodobnie w pewnym momencie wystąpią problemy.

Nawet jeśli używasz wersji środowiska wykonawczego z wątkami Win32, prawdopodobnie nie powinieneś bezpośrednio wywoływać interfejsów API Win32. Cytowanie z FAQ MinGW :

Ponieważ MinGW korzysta ze standardowej biblioteki wykonawczej Microsoft C, która jest dostarczana z systemem Windows, należy zachować ostrożność i użyć odpowiedniej funkcji do wygenerowania nowego wątku. W szczególności CreateThreadfunkcja nie skonfiguruje poprawnie stosu dla biblioteki wykonawczej C. Zamiast tego powinieneś użyć _beginthreadex, który jest (prawie) całkowicie zgodny z CreateThread.

James Holderness
źródło
7
W takim przypadku, co z bibliotekami wątków innych firm, takimi jak boost lub Qt? Czy jest jakiś sposób na używanie tych bibliotek z mingw64 bez konieczności ustalania dla nich podstawowej biblioteki wątków? Co by się stało, gdybym arbitralnie zdecydował się na użycie boost :: thread z wariantem posix mingw?
tantuni
1
@ user460153 some info qt-project.org/wiki/…
Alex V.
10
Ta odpowiedź jest błędna. Środowisko wykonawcze GCC nie ma absolutnie żadnego wpływu na interfejsy API Win32.
rubenvb
Przeczytaj link do wpisu FAQ. Ta odpowiedź jest poprawna.
Daira Hopwood
13

Zauważ, że jest teraz możliwe użycie części C ++ 11 std :: thread w trybie wątków win32. Te adaptery tylko do nagłówka działały dla mnie od razu po wyjęciu z pudełka: https://github.com/meganz/mingw-std-threads

Z historii wersji wygląda na to, że ostatnio podjęto próbę uczynienia tego częścią środowiska wykonawczego mingw64.

Tom 7
źródło