Олег Цилюрик - QNX/UNIX: Анатомия параллелизма

Читать онлайн «QNX/UNIX: Анатомия параллелизма». Страница 66

Автор Олег Цилюрик

Раньше, когда приложение-клиент использовало вызов функции name_open() для связи с сервером, сервер об этом не знал. Теперь это изменено: серверу фактически отсылается сообщение _IO_CONNECT/_IO_OPEN. Кроме того, изменено приложение-сервер, чтобы иметь возможность обрабатывать приход сообщения _IO_CONNECT.

Заключение

Задача проведения сравнительного анализа рассмотренных нами методов организации обмена сообщениями с точки зрения их быстродействия или, скажем, объема исполняемого кода не показалась мне актуальной. Полагаю, что благодаря высокой эффективности механизма как такового различные его реализации не будут кардинально отличаться. А вот с выбором «правильных» критериев есть проблемы, по крайней мере, у меня.

Конечно, первый из рассмотренных методов является самым «спартанским» и поэтому наиболее эффективным по действию, однако и наиболее «хрупким», требующим внимательного обустройства, а также мало приемлемым в больших системах. Лично мне больше импонирует второй метод, но боюсь, что это просто личные пристрастия (возможно, нравится потому, что лентяю не может не доставлять удовольствия тот факт, что предлагается уже готовый прототип менеджера ресурсов, и самому надо делать совсем немного...). Выбирайте то, что больше всего нравится вам и более всего подходит для вашей конкретной задачи.

Литература

1. Роб Кертен «Введение в QNX/Neutrino 2». — СПб.: Петрополис, 2001. — 478 с.

2. Уильям Стивенс «UNIX: взаимодействие процессов». — СПб.: Питер, 2002. — 576 с.

3. Уильям Стивенс «UNIX: разработка сетевых приложений». — СПб.: Питер, 2003. — 1086 с.

4. Алексеев, Видревич, Волков, Горошко, Горчак, Жавнис, Сошин, Цилюрик, Чиликин «Практика работы с QNX». — М.: КомБук, 2004. — 432 с.

5. Кэйт Хэвиленд, Дайна Грей, Бен Салама «Системное программирование в UNIX». — М.: ДМК Пресс, 2000. — 368 с.

6. Теренс Чан «Системное программирование на C++ для UNIX». — К.: Издательская группа BHV, 1997. — 592 с.

7. Андрей Робачевский «Операционная система UNIX». — СПб.: BHV-Санкт-Петербург, 1997. — 528 с.

8. «QNX Neutrino Realtime Operating System. System Architecture». — QNX Software Systems Ltd, 2002.

9. Йон Снейдер «Эффективное программирование TCP/IP». — СПб.: Питер, 2001. — 320 с.

10. Э. Дейкстра «Взаимодействие последовательных процессов», сборник «Языки программирования» под ред. Ф. Женюи. — М.: Мир, 1972.

11. Стивен Янг «Алгоритмические языки реального времени. Конструирование и разработка». — М.: Мир, 1985. — 400 с.

12. Марк Митчелл, Джеффри Оулдем, Алекс Самьюэл «Программирование для Linux. Профессиональный подход». — М.: Издательский дом «Вильямс», 2002. — 288 с.

13. С. L. Liu and J.W. Layland «Scheduling Algorithms for Multiprogramming in a Hard Real-Time Environment», J. CM, Vol. 20, No. 1, Jan.1973, pp. 46-61.

По тому же принципу писались книги, ставшие самыми информативными источниками в мировой практике, например описания Даниэля Нортона по MS-DOS или Джеффри Рихтера по Win32.

Все технические описания QNX API сформированы в ориентации на классический С. Напротив, все используемые в тексте примеры кода излагаются в синтаксисе С++, а прилагаемые к тексту приложения транслированы в С++. Это обусловлено рядом аргументов, которые обсуждать не будем, но отметим, что такое различие подходов в любом случае расширяет информационную базу относительно использования QNX API.

В книге в примерах кода мы часто используем русскоязычные символьные константы для вывода сообщений, например "Получен сигнал SIGINT", что способствует большей доходчивости обсуждаемого кода. Однако в файлах работающих приложений, представленных в архиве, вы увидите только англоязычные эквиваленты выводимых сообщений, поскольку работающие примеры кода являются консольными приложениями, а текстовая консоль QNX не русифицируема в принципе и графические псевдотерминалы (pterm, xterm) имеют определенные сложности.

Это положение напрямую диктуется определением «слабосвязанных процессов», впервые сформулированным Э. Дейкстрой [10]. Заметим, что фундаментальная и стройная «картина мира», выстроенная Э. Дейкстрой и считающаяся классикой, исчерпывающе («необходимо и достаточно») описывает систему процессов равного приоритета. Расширение реальных систем атрибутом приоритета затуманивает прозрачность этой модели и делает все гораздо сложнее…

На сегодняшний день практически ни одна из ОС UNIX уже не может быть отнесена чисто к System V или BSD, во многом исходя именно из требования совместимости с POSIX, который требует одновременного наличия и того и другого API (хотя в каждом случае комплиментарный набор API реализуется как «обертка» к базовому). Одними из первых (к 1997–1998 гг.) ОС, поддерживающих оба набора API, стали Sun Solaris 2.6 и Digital Unix 4.0B [3].

При общей истории UNIX, начинающейся с 1971 г. [7], две ветви API — BSD и System V — в их современном виде сформировались достаточно поздно: BSD к 1983 г., a System V к 1987 г. [3, 7]. Но многие IPC-механизмы System V (например, семафоры) сформировались по времени заметно раньше своих аналогов из BSD. Как отмечается в [3]: «Информация об истории разработки и развитии функций System V IPC не слишком легко доступна <…> очереди сообщений, семафоры и разделяемая память этого типа были разработаны в конце 70х в одном из филиалов Bell Laboratories в городе Колумбус… Эта версия называлась Columbus Unix, или СВ Unix».

[4]: глава Д. Алексеева «Получение системной информации».

Здесь Робачевский мимоходом расширяет понятие процесса и на программу, представленную, например, текстом для интерпретатора shell, или языков Perl, Tcl/Tk, или других интерпретаторов. В контексте нашего обсуждения в случаях выполнения таких «программ» «процессом» будет процесс, интерпретирующий текст скрипта, и именно к нему в полной мере относятся все детали нашего рассмотрения относительно процессов.

Здесь используется терминология [7]; терминология и аббревиатуры для различных клонов UNIX несколько различаются между собой в описывающих их литературных источниках.

Здесь многое зависит от расстановки приоритетов. Если вы хотите, чтобы всякий, читающий ваш код, тут же воскликнул: «Ну и крутой же парень написал такое!», заведомо используйте spawn(). При желании сделать код максимально элегантным используйте fork(), а если ставится задача хорошей читаемости и ясности кода, то очень часто достаточно и system().

Детали создания потока и и частности передачи ему параметра обстоятельно рассматриваются далее.

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

Тем не менее это вовсе не означает, что следует непосредственно использовать вызов spawn(), ведь он самый трудоемкий и чреват ошибками.

Часто в публикациях ссылаются на расширения реального времени POSIX 1003b (1993). Но POSIX 1003b не описывают группу pthread_*, хотя именно в этой редакции определены семафоры sem_t. У. Стивенс [2] указывает, что программные потоки POSIX определены в редакции 1003.1 (1995).

Клонирование многопоточных процессов с помощью fork() — это отдельная песня. Хотя POSIX и предусматривает реализацию (pthread_atfork()) такой возможности, до конца не ясно, как это работает. API QNX предоставляет эту возможность, но предупреждает, что пользователь сам отвечает за последствия. Детали механизма pthread_atfork() см. в справочном руководстве QNX.

Собственно с этим и связано употребление применительно к потокам названия «легкие процессы». Впервые этот термин (LWP — lightweight process) ввела в своей технической документации для обозначения понятия, эквивалентного потоку, фирма Sun Microsystems.

Эта схема PID/TID описана в POSIX, но выполняется далеко не во всех UNIX-совместимых ОС. Например, вплоть до самых последних редакций ядра Linux (ситуация стала меняться только сейчас) процессы (fork()) и потоки (pthread_create()) (создавались на базе единого системного вызова (_clone()) и TID являлись идентификаторами в едином ряду PID. Это может привести к трудно выявляемым ошибкам при переносе программ между двумя ОС.