minimalist - mingw para windows 7 64 bits

hilos mingw-w64: posix vs win32

Question

Estoy instalando mingw-w64 en Windows y hay dos opciones: win32 hilos y posix hilos. Sé cuál es la diferencia entre win32 hilos y pthreads, pero no entiendo cuál es la diferencia entre estas dos opciones. Dudo que si elijo los hilos de posix me impida llamar a las funciones de WinAPI como CreateThread.

Parece que esta opción especifica qué API de threading será utilizada por algún programa o biblioteca, pero ¿por qué? ¿Por GCC, libstdc ++ o por algo más?

Encontré esto: ¿ Cuál es la diferencia entre thread_posixs y thread_win32 en el puerto gcc de Windows?

En resumen, para esta versión de mingw, la versión threads-posix usará la API posix y permitirá el uso de std :: thread, y threads-win32 usará la API win32, y deshabilitará la parte std :: thread de la estándar.

De acuerdo, si selecciono win32 hilos, entonces std :: thread no estará disponible, pero se seguirán utilizando win32 hilos. Pero usado por qué?

Answer 1

Las partes del tiempo de ejecución de GCC (el manejo de excepciones, en particular) dependen del modelo de subprocesamiento que se utiliza. Por lo tanto, si está utilizando la versión del tiempo de ejecución que se creó con los hilos POSIX, pero decide crear subprocesos en su propio código con las API de Win32, es probable que tenga problemas en algún momento.

Incluso si está utilizando la versión de ejecución de Win32 del tiempo de ejecución, probablemente no debería llamar directamente a las API de Win32. Citando de las preguntas más frecuentes de MinGW :

Como MinGW usa la biblioteca de tiempo de ejecución estándar de Microsoft C que viene con Windows, debe tener cuidado y usar la función correcta para generar un nuevo hilo. En particular, la función CreateThread no configurará la pila correctamente para la biblioteca C runtime. Debería usar _beginthreadex en _beginthreadex lugar, que es (casi) completamente compatible con CreateThread .

Answer 2

Tenga en cuenta que ahora es posible utilizar algo de C ++ 11 std :: thread en el modo de enhebrado win32. Estos adaptadores de solo cabecera me funcionaron de forma https://github.com/meganz/mingw-std-threads : https://github.com/meganz/mingw-std-threads

A partir del historial de revisión, parece que hay algún intento reciente de hacer que esto sea parte del tiempo de ejecución de mingw64.

Answer 3

GCC incluye una biblioteca de compilación en tiempo de ejecución (libgcc) que utiliza (entre otras cosas) para proporcionar una abstracción de SO de bajo nivel para la funcionalidad relacionada con el subprocesamiento múltiple en los idiomas que admite. El ejemplo más relevante es el C ++ 11 de libstdc ++ <thread> , <mutex> y <future> , que no tienen una implementación completa cuando se genera GCC con su modelo interno de enhebrado Win32. MinGW-w64 proporciona un winpthreads (una implementación de pthreads sobre la API de subprocesamiento múltiple de Win32) que GCC puede vincular para habilitar todas las características sofisticadas.

Debo enfatizar que esta opción no te prohíbe escribir ningún código que desees ( NO tiene absolutamente ninguna influencia sobre qué API puedes llamar en tu código). Solo refleja las bibliotecas de tiempo de ejecución (libgcc / libstdc ++ / ...) de GCC para su funcionalidad. La advertencia citada por @James no tiene nada que ver con el modelo de subprocesamiento interno de GCC, sino con la implementación de CRT de Microsoft.

Para resumir:

• posix : habilita las características de multihilo C ++ 11 / C11. Hace que libgcc dependa de libwinpthreads, por lo que incluso si no llama directamente a la API pthreads, estará distribuyendo la DLL winpthreads. No hay nada de malo en distribuir una DLL más con su aplicación.
• win32 : sin características de multiprocesamiento C ++ 11.

Tampoco influyen en ningún código de usuario que llame a API Win32 o API pthreads. Siempre puedes usar ambos.