Roscado en C, multiplataforma

Estoy lidiando con un proyecto existente (en C) que actualmente se ejecuta en un solo subproceso, y nos gustaría ejecutarlo en varias plataformas Y tener varios subprocesos. Con suerte, hay una biblioteca para esto, porque, en mi humilde opinión, la API de Win32 es como hurgarse en el ojo repetidamente. Conozco Boost.Thread para C++, pero debe ser C (y compilable en MinGW y gcc). Cygwin no es una opción, lo siento.

Tratar MP abierto API, es multiplataforma y puedes compilarlo con GCC.

Breve descripción de la wikipedia:

OpenMP (Open Multi-Processing) es una interfaz de programación de aplicaciones (API) que admite la programación de multiprocesamiento de memoria compartida multiplataforma en C, C++ y Fortran,[3] en la mayoría de las plataformas, arquitecturas de procesadores y sistemas operativos, incluidos Solaris, AIX, HP-UX, Linux, macOS y Windows. Consiste en un conjunto de directivas de compilador, rutinas de biblioteca y variables de entorno que influyen en el comportamiento en tiempo de ejecución.

Usaría la API de subprocesos POSIX – pthread. Este artículo tiene algunos consejos para implementarlo en Windows y una descarga de solo archivo de encabezado (licencia BSD):

http://locklessinc.com/articles/pthreads_on_windows/

Editar: Usé el proyecto sourceforge pthreads-win32 en el pasado para subprocesos multiplataforma y funcionó muy bien. Las cosas han cambiado desde entonces y el enlace anterior parece más actualizado, aunque no lo he probado. Esta respuesta asume, por supuesto, que los subprocesos están disponibles en sus objetivos que no son de Windows (para Mac / Linux, debería pensar que están, probablemente incluso integrados)

Los subprocesos de Windows tienen una funcionalidad suficientemente diferente en comparación con la de Linux, por lo que tal vez debería considerar dos implementaciones diferentes, al menos si el rendimiento de la aplicación puede ser un problema. Por otro lado, la simple implementación de subprocesos múltiples puede hacer que su aplicación sea más lenta de lo que era antes. Supongamos que el rendimiento es un problema y que los subprocesos múltiples son la mejor opción.

Con los subprocesos de Windows, estoy pensando específicamente en los puertos de finalización de E/S (IOCP) que permiten implementar subprocesos controlados por eventos de E/S que hacen el uso más eficiente del hardware.

Muchas aplicaciones “clásicas” se construyen según el concepto de un subproceso/un socket (/un usuario o similar) donde la cantidad de sesiones simultáneas estará limitada por la capacidad del programador para manejar una gran cantidad de subprocesos (> 1000). El concepto IOCP permite limitar la cantidad de subprocesos a la cantidad de núcleos en su sistema, lo que significa que el programador tendrá muy poco que hacer. Los subprocesos solo se ejecutarán cuando el IOCP los libere después de que haya ocurrido un evento de E/S. El subproceso da servicio al IOC, (típicamente) inicia una nueva E/S y vuelve a esperar en el IOCP para la siguiente finalización. Antes de lanzar un subproceso, el IOCP también proporcionará el contexto de finalización, de modo que el subproceso “sabrá” a qué contexto de procesamiento pertenece el IOC.

El concepto de IOCP elimina por completo el sondeo, que es un gran derrochador de recursos, aunque el sondeo de “esperar en varios objetos” es algo así como una mejora. La última vez que miré, Linux no tenía nada remotamente parecido a los IOCP, por lo que una aplicación de subprocesos múltiples de Linux se construiría de manera bastante diferente en comparación con una aplicación de Windows con IOCP.

En las aplicaciones IOCP realmente eficientes, existe el riesgo de que se pongan en cola tantas E/S (o más bien Salidas) en el recurso de E/S involucrado que el sistema se quede sin memoria no paginada para almacenarlas. Por el contrario, en aplicaciones IOCP realmente ineficientes, existe el riesgo de que tantas entradas estén en cola (esperando ser reparadas) que la memoria no paginada se agote al intentar almacenarlas temporalmente.

Si alguien necesita una solución portátil y liviana para enhebrar en C, eche un vistazo a la plisys biblioteca. Le proporciona administración y sincronización de subprocesos, así como otras características útiles como la implementación de sockets portátiles. Se admiten todos los principales sistemas operativos (Windows, Linux, OS X), también se admiten otros sistemas operativos menos populares (es decir, AIX, HP-UX, Solaris, QNX, IRIX, etc.). En todas las plataformas, solo se utilizan las llamadas nativas para minimizar los gastos generales. La biblioteca está totalmente cubierta con pruebas unitarias que se ejecutan de forma regular.

hilos simplistas se puede compilar multiplataforma.

La “mejor” https://stackoverflow.com/”simplest”/… respuesta aquí es definitivamente pthreads. Es la arquitectura de subprocesamiento nativa en los sistemas Unix/POSIX y funciona casi tan bien en Windows. No hay necesidad de buscar más.

Dado que está restringido con C. Tengo dos sugerencias:

1) He visto un proyecto (similar al tuyo) que tenía que ejecutarse en Windows y Linux con subprocesos. La forma en que se escribió fue que (el mismo código base) usaba pthreads en Linux y win32 threads en Windows. Esto se logró mediante una declaración #ifdef condicional donde sea necesario crear subprocesos, como

#ifdef WIN32

//use win32 threads

#else

//use pthreads

#endif

2) La segunda sugerencia podría ser usar OpenMP. ¿Has considerado OpenMP?

Por favor, avíseme si me perdí algo o si desea más detalles. Estoy felíz de ayudar.

Mejor krishna