ARPACK поточно-ориентированный?

Question

Безопасно ли одновременно использовать программу eigensolver ARPACK из разных потоков из программы, написанной на C? Или, если сама ARPACK не является поточно-ориентированной, существует ли API-совместимая поточно-ориентированная реализация? Быстрый поиск в Google не дал ничего полезного, но, учитывая тот факт, что ARPACK интенсивно используется в больших научных вычислениях, я был бы очень удивлен, когда обнаружил, что первым из них требуется поточно-ориентированный разреженный eigensolver.

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

Answer 1

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

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

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

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

Answer 2

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

Возможно, это то, что делает f2c, и если это так, то это может быть то, что шаг f2c делает программу не поточно-ориентированной, а не саму программу. Конечно, как уже упоминали другие, проверьте и ОБЩИЕ блоки. EDIT : Также проверьте наличие явных директив SAVE. SAVE означает, что значение переменной должно сохраняться между последующими вызовами процедуры, подобно статическому в C. Теперь, выделение всех локальных данных процедуры в разделе данных делает все переменные неявным образом SAVE, и, к сожалению, существует много старых код, который предполагает это, даже если это не гарантируется стандартом Fortran. Такой код, очевидно, не является потокобезопасным. Wrt. В частности, ARPACK, я ничего не могу обещать, но ARPACK, как правило, хорошо рассматривается и широко используется, поэтому я был бы удивлен, если бы он страдал от таких проблем с пылевой колода.

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

РЕДАКТИРОВАТЬ :

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

Answer 3

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

Answer 4

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