Вопросы
Ответы
  Компилятор 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".
Оцените главное преимущество Convex'a !!

4) И еще один вариант того же свойства: пишется однопоточный вариант, а затем адаптируется, но не под библиотеки компилятора Convex C, а под директивы компилятора "#pragma _CNX eklmn". Смотрите детали в "man cc" и на "http://www.csa.ru/CSA/tutor/" в массивном труде "CONVEX SPP: Руководство по программированию".

 

Webmaster

Дата последнего обновления: 18-Jun-2002