Является ли ARPACK потокобезопасным?

Fortran 77 не поддерживает рекурсию, и, следовательно, компилятор, соответствующий стандарту, может размещать все переменные в разделе данных программы; в принципе ни стек, ни куча не нужны [1].

Возможно, это то, что делает f2c, и если это так, то может быть, что шаг f2c делает программу не ориентированной на многопотоковое исполнение, а не сама программа. Конечно, как уже упоминалось, проверьте и блоки COMMON. EDIT: также проверьте наличие явных директив SAVE. SAVE означает, что значение переменной должно сохраняться между последующими вызовами процедуры, аналогично static в C. Теперь размещение всех локальных данных процедуры в разделе данных делает все переменные неявно СОХРАНЕННЫМИ, и, к сожалению, есть много старых код, который предполагает это, даже если это не гарантируется стандартом Fortran. Такой код, очевидно, не является потокобезопасным. Запись В частности, ARPACK, я не могу ничего обещать, но ARPACK, как правило, хорошо известен и широко используется, поэтому я был бы удивлен, если бы он страдал от таких проблем с пыльной палубой.

Большинство современных компиляторов Фортрана используют выделение стека. Возможно, вам повезет больше, если вы скомпилируете ARPACK, скажем, с помощью gfortran и опции -frecursive.

ИЗМЕНИТЬ:

[1] Не потому, что он более эффективен, а потому, что Фортран изначально был разработан до того, как были изобретены стеки и кучи, и по какой-то причине комитет по стандартам хотел сохранить возможность реализации Фортрана на оборудовании без поддержки ни стека, ни кучи вплоть до Fortran 90. На самом деле, я предполагаю, что стеки более эффективны на сегодняшнем оборудовании, сильно зависящем от кэша, чем доступ к локальным данным процедуры, которые разбросаны по всему разделу данных.

Я преобразовал ARPACK в C, используя f2c. Всякий раз, когда вы используете f2c и заботитесь о безопасности потоков, вы должны использовать переключатель -a. Это приводит к тому, что локальные переменные имеют aавтоматическое хранение, т. е. локальные переменные на основе стека, а не статические значения, которые используются по умолчанию.

Несмотря на это, сам ARPACK определенно не является потокобезопасным. Он использует много общих блоков (т. е. глобальных переменных) для сохранения состояния между различными вызовами его функций. Если мне не изменяет память, он использует интерфейс обратной связи, что приводит разработчиков к использованию глобальных переменных. И, конечно же, ARPACK, вероятно, был написан задолго до того, как многопоточность стала обычным явлением.

В итоге я переработал преобразованный код C, чтобы систематически удалить все глобальные переменные. Я создал несколько структур C и постепенно переместил глобальные переменные в эти структуры. Наконец, я передал указатели на эти структуры каждой функции, которой требовался доступ к этим переменным. Хотя я мог бы просто преобразовать каждую глобальную переменную в параметр там, где это необходимо, гораздо чище было хранить их все вместе, в структурах.

По сути, идея состоит в том, чтобы преобразовать глобальные переменные в локальные переменные.

ARPACK использует BLAC, верно? Тогда эти библиотеки также должны быть потокобезопасными. Я считаю, что ваша идея проверить с помощью f2c может не быть пуленепробиваемым способом определить, является ли код Fortran потокобезопасным, я предполагаю, что это также зависит от компилятора Fortran и библиотек.

Я не знаю, какую стратегию f2c использует при переводе Fortran. Поскольку ARPACK написан на FORTRAN 77, первое, что нужно сделать, это проверить наличие блоков COMMON. Это глобальные переменные, и если они используются, код, скорее всего, не является потокобезопасным. Веб-страница ARPACK, http://www.caam.rice.edu/software/ARPACK/, говорит, что существует параллельная версия -- вполне вероятно, что эта версия потокобезопасна.