mingw-w64线程:posix vs win32。

时间:2022-12-25 07:10:14

I'm installing mingw-w64 on Windows and there are two options: win32 threads and posix threads. I know what is the difference between win32 threads and pthreads but I don't understand what is the difference between these two options. I doubt that if I will choose posix threads it will prevent me from calling WinAPI functions like CreateThread.

我在Windows上安装mingw-w64,有两个选项:win32线程和posix线程。我知道win32线程和pthreads之间的区别,但是我不明白这两个选项之间的区别。我怀疑如果我选择posix线程,它将阻止我调用WinAPI函数,比如CreateThread。

It seems that this option specify which threading API will be used by some program or library, but by what? By GCC, libstdc++ or by something else?

似乎这个选项指定了某个程序或库将使用哪个线程API,但是通过什么呢?通过GCC, libstdc++或其他什么?

I found this: Whats the difference between thread_posixs and thread_win32 in gcc port of windows?

我发现:在windows的gcc端口中,thread_posixs和thread_win32的区别是什么?

In short, for this version of mingw, the threads-posix release will use the posix API and allow the use of std::thread, and the threads-win32 will use the win32 API, and disable the std::thread part of the standard.

简而言之,对于这个版本的mingw, thread -posix版本将使用posix API并允许使用std::thread,而threads-win32将使用win32 API,并禁用std::标准的线程部分。

Ok, if I will select win32 threads then std::thread will be unavailable but win32 threads will still be used. But used by what?

好的,如果我选择win32线程,那么std::线程将不可用,但是仍然会使用win32线程。但用什么?

3 个解决方案

#1


59  

GCC comes with a compiler runtime library (libgcc) which it uses for (among other things) providing a low-level OS abstraction for multithreading related functionality in the languages it supports. The most relevant example is libstdc++'s C++11 <thread>, <mutex>, and <future>, which do not have a complete implementation when GCC is built with its internal Win32 threading model. MinGW-w64 provides a winpthreads (a pthreads implementation on top of the Win32 multithreading API) which GCC can then link in to enable all the fancy features.

GCC提供了一个编译器运行时库(libgcc),它使用它来为多线程的相关功能提供底层的OS抽象。最相关的例子是libstdc++'s c++ 11 ,当GCC使用内部Win32线程模型构建时,它没有完整的实现。MinGW-w64提供了一个winpthreads(在Win32多线程API之上的一个pthreads实现),GCC可以链接到它来启用所有的高级特性。

I must stress this option does not forbid you to write any code you want (it has absolutely NO influence on what API you can call in your code). It only reflects what GCC's runtime libraries (libgcc/libstdc++/...) use for their functionality. The caveat quoted by @James has nothing to do with GCC's internal threading model, but rather with Microsoft's CRT implementation.

我必须强调这个选项并不禁止您编写任何您想要的代码(它对您在代码中调用的API完全没有影响)。它只反映了GCC的运行时库(libgcc/libstdc+ /…)的功能。@James所引用的警告与GCC的内部线程模型无关,而是与微软的CRT实现有关。

To summarize:

总结:

  • posix: enable C++11/C11 multithreading features. Makes libgcc depend on libwinpthreads, so that even if you don't directly call pthreads API, you'll be distributing the winpthreads DLL. There's nothing wrong with distributing one more DLL with your application.
  • posix:启用c++ 11/C11多线程特性。使libgcc依赖于libwinpthreads,因此即使不直接调用pthreads API,也会分发winpthreads DLL。在应用程序中再分配一个DLL是没有错的。
  • win32: No C++11 multithreading features.
  • win32:没有c++ 11多线程特性。

Neither have influence on any user code calling Win32 APIs or pthreads APIs. You can always use both.

对任何调用Win32 api或pthreads api的用户代码都没有影响。两者都可以用。

#2


15  

Parts of the GCC runtime (the exception handling, in particular) are dependent on the threading model being used. So, if you're using the version of the runtime that was built with POSIX threads, but decide to create threads in your own code with the Win32 APIs, you're likely to have problems at some point.

GCC运行时的部分(特别是异常处理)依赖于正在使用的线程模型。因此,如果您使用的是使用POSIX线程构建的运行时版本,但是决定使用Win32 api在自己的代码中创建线程,那么在某个时间点可能会出现问题。

Even if you're using the Win32 threading version of the runtime you probably shouldn't be calling the Win32 APIs directly. Quoting from the MinGW FAQ:

即使您正在使用运行时的Win32线程版本,您也不应该直接调用Win32 api。引用了MinGW FAQ:

As MinGW uses the standard Microsoft C runtime library which comes with Windows, you should be careful and use the correct function to generate a new thread. In particular, the CreateThread function will not setup the stack correctly for the C runtime library. You should use _beginthreadex instead, which is (almost) completely compatible with CreateThread.

由于MinGW使用的是标准的Microsoft C运行时库,它附带Windows,所以您应该小心使用正确的函数来生成一个新线程。特别是,CreateThread函数不会正确地为C运行时库设置堆栈。相反,应该使用_beginthreadex,它几乎完全与CreateThread兼容。

#3


9  

Note that it is now possible to use some of C++11 std::thread in the win32 threading mode. These header-only adapters worked out of the box for me: https://github.com/meganz/mingw-std-threads

注意,现在可以在win32线程模式中使用一些c++ 11 std::线程。这些仅由header的适配器为我工作:https://github.com/meganz/mingw-std-threads。

From the revision history it looks like there is some recent attempt to make this a part of the mingw64 runtime.

从修订的历史来看,似乎有一些最近的尝试使这成为mingw64运行时的一部分。

#1


59  

GCC comes with a compiler runtime library (libgcc) which it uses for (among other things) providing a low-level OS abstraction for multithreading related functionality in the languages it supports. The most relevant example is libstdc++'s C++11 <thread>, <mutex>, and <future>, which do not have a complete implementation when GCC is built with its internal Win32 threading model. MinGW-w64 provides a winpthreads (a pthreads implementation on top of the Win32 multithreading API) which GCC can then link in to enable all the fancy features.

GCC提供了一个编译器运行时库(libgcc),它使用它来为多线程的相关功能提供底层的OS抽象。最相关的例子是libstdc++'s c++ 11 ,当GCC使用内部Win32线程模型构建时,它没有完整的实现。MinGW-w64提供了一个winpthreads(在Win32多线程API之上的一个pthreads实现),GCC可以链接到它来启用所有的高级特性。

I must stress this option does not forbid you to write any code you want (it has absolutely NO influence on what API you can call in your code). It only reflects what GCC's runtime libraries (libgcc/libstdc++/...) use for their functionality. The caveat quoted by @James has nothing to do with GCC's internal threading model, but rather with Microsoft's CRT implementation.

我必须强调这个选项并不禁止您编写任何您想要的代码(它对您在代码中调用的API完全没有影响)。它只反映了GCC的运行时库(libgcc/libstdc+ /…)的功能。@James所引用的警告与GCC的内部线程模型无关,而是与微软的CRT实现有关。

To summarize:

总结:

  • posix: enable C++11/C11 multithreading features. Makes libgcc depend on libwinpthreads, so that even if you don't directly call pthreads API, you'll be distributing the winpthreads DLL. There's nothing wrong with distributing one more DLL with your application.
  • posix:启用c++ 11/C11多线程特性。使libgcc依赖于libwinpthreads,因此即使不直接调用pthreads API,也会分发winpthreads DLL。在应用程序中再分配一个DLL是没有错的。
  • win32: No C++11 multithreading features.
  • win32:没有c++ 11多线程特性。

Neither have influence on any user code calling Win32 APIs or pthreads APIs. You can always use both.

对任何调用Win32 api或pthreads api的用户代码都没有影响。两者都可以用。

#2


15  

Parts of the GCC runtime (the exception handling, in particular) are dependent on the threading model being used. So, if you're using the version of the runtime that was built with POSIX threads, but decide to create threads in your own code with the Win32 APIs, you're likely to have problems at some point.

GCC运行时的部分(特别是异常处理)依赖于正在使用的线程模型。因此,如果您使用的是使用POSIX线程构建的运行时版本,但是决定使用Win32 api在自己的代码中创建线程,那么在某个时间点可能会出现问题。

Even if you're using the Win32 threading version of the runtime you probably shouldn't be calling the Win32 APIs directly. Quoting from the MinGW FAQ:

即使您正在使用运行时的Win32线程版本,您也不应该直接调用Win32 api。引用了MinGW FAQ:

As MinGW uses the standard Microsoft C runtime library which comes with Windows, you should be careful and use the correct function to generate a new thread. In particular, the CreateThread function will not setup the stack correctly for the C runtime library. You should use _beginthreadex instead, which is (almost) completely compatible with CreateThread.

由于MinGW使用的是标准的Microsoft C运行时库,它附带Windows,所以您应该小心使用正确的函数来生成一个新线程。特别是,CreateThread函数不会正确地为C运行时库设置堆栈。相反,应该使用_beginthreadex,它几乎完全与CreateThread兼容。

#3


9  

Note that it is now possible to use some of C++11 std::thread in the win32 threading mode. These header-only adapters worked out of the box for me: https://github.com/meganz/mingw-std-threads

注意,现在可以在win32线程模式中使用一些c++ 11 std::线程。这些仅由header的适配器为我工作:https://github.com/meganz/mingw-std-threads。

From the revision history it looks like there is some recent attempt to make this a part of the mingw64 runtime.

从修订的历史来看,似乎有一些最近的尝试使这成为mingw64运行时的一部分。