mingw-w64 hilos: posix vs win32

Question

mingw-w64 hilos: posix vs win32

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

Parece que esta opción especifica qué API de subprocesos 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 los threads-win32 usarán la API win32, y deshabilitarán la parte std::thread del estándar.

Ok, si selecciono los hilos win32 entonces std::thread no estará disponible pero los hilos win32 todavía se usarán. ¿Pero usado por qué?

79

windows gcc pthreads mingw

Author: Community, 2013-06-21

Source

3 answers

Partes del tiempo de ejecución de GCC (el manejo de excepciones, en particular) dependen del modelo de subproceso que se esté utilizando. Por lo tanto, si está utilizando la versión del tiempo de ejecución que se creó con subprocesos 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 subproceso de Win32 del tiempo de ejecución, probablemente no debería llamar a las API de Win32 directamente. Citando de la MinGW Preguntas frecuentes :

Como MinGW utiliza 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 de tiempo de ejecución de C. Debe usar _beginthreadex en su lugar, que es (casi) completamente compatible con CreateThread.

15

Author: James Holderness,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2016-05-21 04:27:25

Tenga en cuenta que ahora es posible usar algo de C++11 std::thread en el modo de subproceso win32. Estos adaptadores de encabezado solo funcionaron fuera de la caja para mí: https://github.com/meganz/mingw-std-threads

Del historial de revisiones parece que hay algún intento reciente de hacer esto parte del tiempo de ejecución de mingw64.

10

Author: Tom 7,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2015-09-19 15:32:58

score 69 · Accepted Answer

GCC viene con una biblioteca de tiempo de ejecución del compilador (libgcc) que utiliza para (entre otras cosas) proporcionar una abstracción del sistema operativo de bajo nivel para la funcionalidad relacionada con multihilo en los idiomas que soporta. El ejemplo más relevante es libstdc++'s C++11 <thread>, <mutex>, y <future>, que no tienen una implementación completa cuando GCC está construido con su interior Win32 modelo de subprocesamiento. MinGW-w64 proporciona un winpthreads (una implementación de pthreads en la parte superior de la API multithreading Win32) que GCC puede entonces enlace para habilitar todas las funciones de lujo.

Debo enfatizar que esta opción no le prohíbe escribir cualquier código que desee (tiene absolutamente NO influencia sobre qué API puede llamar en su código). Solo refleja las bibliotecas de tiempo de ejecución de GCC (libgcc / libstdc++/...) utilizar para su funcionalidad. La advertencia citada por @ James no tiene nada que ver con el modelo de enhebrado interno de GCC, sino más bien con la implementación de CRT de Microsoft.

Para resumir:

posix: habilitar Funciones multihilo de C++11/C11. Hace que libgcc dependa de libwinpthreads, de modo que incluso si no llamas directamente a la API de pthreads, estarás distribuyendo la DLL de winpthreads. No hay nada malo en distribuir una DLL más con tu aplicación.
win32: Sin funciones de multiproceso de C++11.

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