He convertido ARPACK a C usando f2c . Siempre que uses f2c y te preocupa la seguridad de los subprocesos, debes usar el -a cambiar. Esto hace que las variables locales tengan a almacenamiento automático, es decir, ser locales basados en pilas en lugar de estáticos, que es el valor predeterminado.
Aun así, ARPACK en sí mismo definitivamente no es seguro para subprocesos. Utiliza muchos bloques comunes (es decir, variables globales) para preservar el estado entre diferentes llamadas a sus funciones. Si la memoria no me falla, utiliza una interfaz de comunicación inversa que tiende a llevar a los desarrolladores a utilizar variables globales. Y, por supuesto, ARPACK probablemente se escribió mucho antes de que los subprocesos múltiples fueran comunes.
Terminé reelaborando el código C convertido para eliminar sistemáticamente todas las variables globales. Creé un puñado de estructuras C y moví gradualmente las variables globales a estas estructuras. Finalmente pasé punteros a estas estructuras a cada función que necesitaba acceso a esas variables. Aunque podría haber convertido cada global en un parámetro donde fuera necesario, era mucho más sencillo mantenerlos todos juntos, contenidos en estructuras.
Básicamente, la idea es convertir variables globales en variables locales.
Fortran 77 no admite la recursividad y, por lo tanto, un compilador que cumpla con los estándares puede asignar todas las variables en la sección de datos del programa; en principio, no se necesita ni una pila ni un montón [1].
Puede ser que esto sea lo que está haciendo f2c, y si es así, puede ser que sea el paso f2c lo que hace que el programa no sea seguro para subprocesos, en lugar del programa en sí. Por supuesto, como otros han mencionado, busque también bloques COMUNES. EDITAR :Además, verifique las directivas SAVE explícitas. GUARDAR significa que el valor de la variable debe conservarse entre invocaciones subsiguientes del procedimiento, de forma similar a lo estático en C. Ahora, la asignación de todos los datos locales del procedimiento en la sección de datos hace que todas las variables sean implícitamente GUARDAR y, desafortunadamente, hay muchos datos antiguos. código que asume esto a pesar de que no está garantizado por el estándar Fortran. Dicho código, obviamente, no es seguro para subprocesos. escritura ARPACK específicamente, no puedo prometer nada, pero ARPACK es generalmente bien considerado y ampliamente utilizado, por lo que me sorprendería si sufriera este tipo de problemas de cubierta polvorienta.
La mayoría de los compiladores de Fortran modernos utilizan la asignación de pila. Es posible que tenga más suerte compilando ARPACK con, por ejemplo, gfortran y la opción -frecursiva.
EDITAR :
[1] No porque sea más eficiente, sino porque Fortran se diseñó originalmente antes de que se inventaran las pilas y los montones, y por alguna razón el comité de estándares quería conservar la opción de implementar Fortran en hardware sin soporte de pilas ni montones hasta Fortran 90. En realidad, supongo que las pilas son más eficientes en el hardware actual que depende en gran medida de la memoria caché en lugar de acceder a los datos locales del procedimiento que se distribuyen por toda la sección de datos.