|
Вопросы
|
Ответы
|
|
Компилятор cc (gcc) на SPP
|
|
| 1. На SPP не удалось обнаружить компоненты cc (gcc), необходимые для многопотокового программирования: файлы <thread.h> или <pthread.h> ... Идеально это все установлено, настроено и работает на chip.csa.ru . |
В нашем случае существует три (а вообще их еще больше) стандарта на программный интерфейс работы с потоками: 1. в ОС Solaris семейство функций thr_op, файл <thread.h> 2. в ОС SPP-UX в наследство от Convex'а остались функции семейства cnx_thread_op, файл <sys/cnx_thread.h> 3. существует стандарт PTHREADS (Posix Threads), заголовочный файл <pthread.h> Стандарты 1 и 2 появились раньше, чем 3. Стандарт Posix Threads входит также в DEC OSF/1, и все необходимые компоненты поставляются для HP-UX в составе клиентского обеспечения DCE (Distributed Computing Environment), которое у нас в институте есть как часть стандартной поставки от HP. После установки появляются все необходимые библиотеки и заголовочные файлы (/usr/include/pthread.h) , и все прекрасно работает. Третий вариант является наиболее "правильным" с точки зрения соответствия стандартам. В Solaris'e реализованы 1 и 3. Какой из них Вы используете сейчас? Допустим, на SPP Вам нужны PTHREADS. Тут можно двигаться в одном из трех направлений: 1) Взять наиболее мобильную реализацию PTHREADS: "http://www.mit.edu/people/proven/IAP_2000/index.html". Она, кажется, даже на SPP работает. Главный недостаток: многопоточность там не с квантованием времени, а вытесняющая. Это, в частности, означает, что программа, написанная на PTHREADS, использует ровно один процессор. На SPP такая программа будет работать медленнее, чем на PC... 2) Забрать у HP последнюю версию компилятора Си, библиотека которого, насколько я понял, реализацию PTHREADS содержит. Главный недостаток: это может оказаться не бесплатным. И даже если это бесплатно, все равно заказ сможет сделать только сам администратор SPP, имея на руках номер нашей институтской лицензии. И он же должен будет переставлять все полученное ПО - тоже задача не для слабонервных. 3) Продолжать искать свободно распространяемую реализацию PTHREADS, основанную на квантовании времени, работающую либо могущую быть легко перенесенной на SPP-UX. Ниже следует некий набор сиюминутных немобильных (пригодных только для SPP) решений, которые, однако, имеют то неоспоримое достоинство, что никого, кроме Вас, не напрягают: 1) Если Вы используете thr_op, то Вам так или иначе для переноса за пределы Solaris'a придется свою программу переписать. Перепишите ее, используя cnx_thread. Делайте в исходном тексте проверку "#ifdef __HP_CXD_SPP". 2) Даже если программа и использует PTHREADS, может быть, можно все-таки адаптировать ее под cnx_thread ? 3) Программа переписывается в однопотоковом виде, без всяких намеков
на распараллеленность, и затем компилируется с ключами автоматической
оптимизации. Про эти ключи читайте в "man cc" или "man fort77", раздел
"OPTIMIZATION". 4) И еще один вариант того же свойства: пишется однопоточный вариант, а затем адаптируется, но не под библиотеки компилятора Convex C, а под директивы компилятора "#pragma _CNX eklmn". Смотрите детали в "man cc" и на "http://www.csa.ru/CSA/tutor/" в массивном труде "CONVEX SPP: Руководство по программированию". |
Webmaster