Текст книги "QNX/UNIX: Анатомия параллелизма"

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

Соавторы: Владимир Зайцев,Егор Горошко
сообщить о нарушении

Текущая страница: 1 (всего у книги 23 страниц) [доступный отрывок для чтения: 9 страниц]

QNX/UNIX
Анатомия параллелизма
Олег Цилюрик, Егор Горошко

Предисловие

Зачем написана эта книга и кому она предназначена? Различные аспекты построения программных приложений для операционной системы реального времени QNX, родственные тем, которые мы обсуждаем в данном издании, весьма обстоятельно описаны в литературе. Это и основополагающие труды Э. Дейкстры [10] и других авторов, и общая литература по POSIX (Portable Operating System Interface) и ОС UNIX [2, 3, 5–7]. Другие, сугубо специфические аспекты для ОС QNX, такие как обмен сообщениями микроядра, построение менеджеров ресурсов, пулы потоков и еще ряд других приятных вещей, прекрасно описаны в книге Р. Кертена [1].

Однако все эти источники имеют ряд недостатков:

• Техническая документация по QNX, тщательно описывающая API и детали реализации, оставляет в стороне (возможно, как относительно известные) общие вопросы построения параллельных приложений и их взаимодействия.

• Несмотря на наличие множества кратких примеров кода по использованию отдельныхвызовов API, в технической документации явно недостаточно примеров их применения в логической последовательности и организации их совместного взаимодействия.

• Издания по UNIX, посвященные общим вопросам, напротив, изобилуют образцами кода, но в силу объективных причин, связанных с длительностью издательского процесса, не отображают новые механизмы, появившиеся в стандартах начиная с конца 90-х годов.

• И наконец, подавляющее большинство переводных книг по программированию для UNIX рассчитано на начальный уровень. Счастливое исключение – книги У. Стивенса, которые мы с удовольствием используем сами и рекомендуем читателям.

В итоге возник замысел написать книгу, в которой будет подведен итог некоторого периода нашего собственного использования ОС QNX и которая будет насыщена примерами в виде законченных проектов или отдельных фрагментов кода. Для удобства читателей *.tgz-архив описываемых в книге приложений размещен по адресу http://www.symbol.ru/library/qnx-unix/pthread.tgz, что позволит полноценно работать с текстом.

По большей части проекты трансформировались из реальных задач, из которых исключалась вся специфика конкретного заказа, только затуманивающая смысл примера. Многие примеры программного кода и приложения подготовлены так, что несут двойную нагрузку: они построены как тесты тех или иных механизмов ОС и, иллюстрируя рассматриваемые аспекты, одновременно позволяют получить численные характеристики тестируемых параметров. Этим книга существенно отличается от технической документации и описательных статей по QNX, которые не слишком богаты численными показателями, подтверждающими то, о чем в них говорится.

Первоначально предполагалось создать достаточно компактный текст, систематизирующий механизмы, итак хорошо известные и понятные… Но по ходу работы объем материала, который необходимо было хотя бы затронуть, начал разрастаться как снежный ком: уточнение незначительного вопроса порождало два новых и часто гораздо более существенных, чем первоначальный; начали «вылезать» несоответствия документации и результатов тестирования; слабо связанные, на первый взгляд, механизмы (например, примитивы синхронизации POSIX и сигналы UNIX) при перекрестном взаимодействии порождают такие эффекты, которые просто нельзя оставить без внимания.

Для того чтобы хоть как-то бороться с лавинным нарастанием объема, было принято решение выделить те механизмы, программные техники и элементы API, которые наиболее слабо затронуты в литературных источниках, и рассматривать их с максимально возможной обстоятельностью (это относится, например, к базовой форме вызова spawn()). Напротив, те элементы, которые достаточно детально описаны и обсуждены или интуитивно понятны (например, все семейство вызовов [1], производных от spawn()), лишь поверхностно перечисляются (даже если позже в примерах кода мы и используем именно эти формы). В конце концов, мы не собирались пересказывать техническую документацию QNX, а хотели детально рассмотреть тонкие механизмы и их несоответствия (между собой или с изложением в документации) на работающих образцах кода.

При написании этого материала нам не были доступны никакие внутренние или специфические материалы разработчиков, кроме официальной технической документации ОС QNX, общедоступной литературы, информации, циркулирующей в Интернете в обсуждениях QNX-сообществ (в первую очередь http://qnx.org.ruи http://qnxclub.net), и контактов с коллегами-разработчиками. Многие тонкие детали приходилось восстанавливать путем тестирования и последующего толкования наблюдаемых результатов.

Как следствие, совершенно не исключено, что некоторые полученные нами результаты были неверно интерпретированы, а описания содержат определенные неточности – текущее состояние текста отображает наше сегодняшнеепонимание наблюдаемых процессов и механизмов в системе, оно может измениться уже завтра. Мы были бы в высшей степени признательны за всякое указание на сомнительные в этом смысле места, что поможет сделать этот текст максимально адекватным и пригодным для использования.

Более того, не все наши вопросы к системе на сегодняшний день находят удовлетворительное решение – в силу ли ошибочной интерпретации процессов, наблюдаемых нами в системе, или в силу наличия в системе естественных «узлов и закрутов» (А. Ремизов), который мы пока не в состоянии раскрутить. На таких вопросах мы сознательно акцентируем внимание, даже если пока и не можем предложить на них удовлетворительных ответов.

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


[Закрыть]есть и своя положительная оборотная сторона: описанные и тестированные фрагменты кода отображают состояние и функционирование механизмов ОС «как они есть», а не «как они должны быть». Это вдвойне актуально, учитывая, что разработчик QNX, фирма QSSL, не раз в своей технической документации описывала компоненты как реально существующие, в то время как их только предполагалось реализовать в последующих версиях (маршрутизация QNET «над» IP, механизмы shared memory и др.), или описывала механизмы в таком туманном изложении (дисциплины балансировки нагрузки QoS, НАМ), что трудно понять, в какой степени они уже пригодны к практическому применению, а в какой – являются лишь экспериментальными наработками на будущее.

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

Примечание

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


[Закрыть]и имеет некоторый опыт в описываемой области по другим ОС (Linux, MS-DOS, MS Windows и др.). На основах программной техники мы останавливаться не будем, многие образцы кода, использующие общеизвестные и часто употребляемые приемы, будут даваться без комментариев. Более того, текст на протяжении книги очень «неровный» по глубине изложения. Например, текст приложения, предложенный В. Зайцевым, требует существенных предварительных знаний, а еще лучше – опыта разработки в QNX. Однако при первом чтении такие «усложненные» фрагменты могут быть опущены без ущерба для понимания основного материала.

И наконец, последнее (по порядку, но не по значимости); большая часть излагаемого материала и образцов программного кода базируется на POSIX-стандартизованных механизмах (там, где обратное не оговорено особо) и поэтому может быть отнесена не только к ОС QNX, но и расширена на другие UNIX-подобные системы. Мы же в подавляющем большинстве примеров кода для программной проверки своих положений в качестве эталонной платформы используем ОС QNX как одну из доступных систем UNIX.

На основе ревизии последних лет можно сказать, что в QNX механизмы POSIX реализованы наиболее полно и последовательно относительно других систем, однако и в среде других ОС проводится активная работа по приведению их API в точное соответствие с POSIX. Один из примеров подобной эволюции в ОС Linux мы рассматриваем в тексте; в среде ОС NetBSD заявлено о приведении к соответствию с расширениями POSIX реального времени механизмов потоков и синхронизации. Большая часть кода, приводимого в тексте, может быть перенесена (иногда с незначительными изменениями) в другие системы: Linux, FreeBSD, NetBSD и проч. Отличия же в деталях функционировании рассматриваемых механизмов в разных системах, наоборот, только помогают прояснить детальную картину происходящего. Именно поэтому эта двойственность и была вынесена в заголовок книги: «QNX/UNIX».

Теперь несколько слов о многочисленных примерах программного кода в тексте. Так уж получилось, что по ходу работы над текстом мы постепенно стали нацеливать программные примеры под тестирование возможностей и эффективности иллюстрируемых программных механизмов. Однако такая ориентация, попутно предоставляющая разработчику количественные ориентиры по ОС, не должна затуманивать главное предназначение примеров кода: в них мы стараемся наиболее широко манипулировать разнообразными средствами API, с тем чтобы фрагменты этого кода могли быть непосредственно заимствованы читателями для своих будущих проектов и далее развивались там. Тем не менее в некоторых случаях мы показываем в коде, «как это можно сделать» (когда нужно иллюстрировать специфический механизм), но это вовсе не значит, что «так нужно делать» из соображений производительности, переносимости и т.д. Программный код всех примеров и все необходимое для их сборки, исполнения и проверки находятся в составе файлов архива, доступного по адресу http://www.symbol.ru/library/qnx-unix/pthread.tgz.

Чего нет в этой книге…

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

• Общие UNIX-механизмы IPC (Inter Process Communication). Из всех механизмов, традиционно относимых к IPC, мы детально затрагиваем только один – сигналы. Другие, крайне интересные в применениях и полноценно представленные в API QNX, такие как неименованные (pipe) и именованные (FIFO) каналы, очереди сообщений POSIX ( mq_*), блокирование записей и файлов ( fcntl()) и ряд других механизмов, полностью и сознательно обойдены вниманием. Это связано с тем, что: а) в программирование этих механизмов мало что привносит именно «потоковая» (thread) ориентация, положенная во главу угла нашего рассмотрения; б) эти механизмы настолько исчерпывающе описаны У. Стивенсом [2], что добавить что-либо трудно; в) нам крайне не хотелось раздувать объем текста сверх некоторой разумной меры без крайней на то необходимости.

• Совместно используемая (разделяемая) память (shared memory). Это также один из механизмов, традиционно относимый к подмножеству IPC, но мы его выделяем особо. Это именно тот механизм, который должен быть описан применительно к QNX самым тщательным образом, но… Самые поверхностные эксперименты наводят на мысль, что именно в QNX реализации механизмов разделяемой памяти выполнены достаточно «рудиментарно»: ряд возможностей, рассматриваемых POSIX как стандартные, не реализован или реализован в ограниченной мере. Поэтому механизмы разделяемой памяти в QNX требуют отдельного пристального изучения и тестирования. Возможно, это должно быть сделано в отдельной публикации, что мы и планируем восполнить в ближайшем будущем.

• Таймеры в системе. Таймерные механизмы в QNX развиты в полной мере, что неудивительно для ОС реального времени, ориентированной во многом на «встраиваемые» (embedded) применения. Однако таймеры а) имеют все же косвенное отношение к вопросам параллелизма и синхронизации и б) блестяще и полно описаны Р. Кертеном [1].

Вообще, при отборе материала для книги мы старались максимально придерживаться следующего алгоритма: чем шире некоторый предмет освещен в литературе (объект или механизм ОС, приемы его использования и тому подобное), по крайней мере, в известной нам литературе, тем меньше внимания мы уделяли ему в своем тексте.

Благодарности

Предварительный вариант книги был вынесен на обсуждение широкой QNX-общественности (да и UNIX/Linux) на форуме http://qnxclub.net. Было высказано столько замечаний, пожеланий и рекомендаций, что окончательный текст, и котором все они были учтены, стал радикально отличаться от исходной редакции. Невозможно перечислить всех членов интернет-сообщества (в первую очередь, конечно, http://qnx.org.ruи http://qnxclub.net), кто внес свой вклад в это издание – мы благодарны всем без исключения. Но особую признательность мы выражаем:

• Владимиру Зайцеву из г. Харькова, который не только предоставил свой авторский материал, составивший отдельное, самоценное приложение, дополнившее книгу, но и обстоятельно вычитал весь остальной текст, а также внес ряд весьма ценных уточнений.

• Евгению Видревичу из г. Монреаля, который вычитал весь текст с позиции профессионального разработчика и указал на ряд сомнительных мест, а вместо некоторых наших путаных и не совсем внятных формулировок предложил свои – ясные и прозрачные.

• Евгению Тарнавскому из г. Харькова, который высказал ряд очень точных рекомендаций и замечаний, нашедших свое отражение в окончательном варианте текста.

Типографские соглашения

В тексте содержится множество ссылок на программные конструкции: фрагменты кода, имена функций API, символические константы и многое другое, которые при их использовании должны в неизменном виде (именно в таком написании) «перекочевывать» в программный код. Такие фрагменты, конструкции и лексемы выделены моноширинным шрифтом, например pthread_create().

Фрагменты текста, цитируемые из указанных источников, выделены курсивом. Таких мест очень немного: прямое цитирование допускалось нами только в отношении крайне принципиальных утверждений.

В отличие от коротких (в две-три строки) фрагментов кода, листинги программ, приводимых и обсуждаемых в тексте, предваряются отчетливо выделенным заголовком. Это указывает на то, что данную программу как законченную программную единицу можно найти в архиве по адресу http://www.symbol.ru/library/qnx-unix/pthread.tgz. Помимо крупных законченных проектов там же можно найти и отдельные фрагменты кода, обсуждаемые в тексте. Для удобства поиска названия программных файлов, содержащихся в архиве, приводятся в тексте книги перед соответствующим кодом в скобках, например ( файл s2.cc). [3]3
  В книге в примерах кода мы часто используем русскоязычные символьные константы для вывода сообщений, например «Получен сигнал SIGINT», что способствует большей доходчивости обсуждаемого кода. Однако в файлах работающих приложений, представленных в архиве, вы увидите только англоязычные эквиваленты выводимых сообщений, поскольку работающие примеры кода являются консольными приложениями, а текстовая консоль QNX не русифицируема в принципе и графические псевдотерминалы (pterm, xterm) имеют определенные сложности.


[Закрыть]

1. Введение

Параллелизм

Феномен параллелизма при выполнении принципиально последовательного по своей природе компьютерного кода возникает даже раньше, чем он начинает отчетливо требоваться для многозадачных и многопользовательских операционных систем:

• Код обработчиков аппаратных прерываний, являющихся принципиально асинхронными, в самых последовательных ОС выполняется параллельно прерываемому ими коду.

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

Примечание

Например, в принципиально однозадачной операционной системе MS-DOS исторически первой службой, требующей параллельного выполнения, была подсистема спулинга печати. Но добавлять ее в систему пришлось «по живому», поскольку основная структура системы уже сложилась и стабилизировалась (к версии 2.x), а механизмы параллелизма в этой структуре были изначально отвергнуты на корню. И с этого времени начинается затянувшаяся на многие годы история развития уродливой надстройки над MS-DOS – технологии создания TSR-приложений (terminate and stay resident), программного мультиплексора INT 2F и других.

Новое «пришествие» механизмов параллельного выполнения (собственно, уже хорошо проработанных к этому времени в отрасли мэйнфреймов) начинается с появлением многозадачных ОС, разделяющих по времени выполнение нескольких задач. Для формализации (и стандартизации поведения) развивающихся параллельно программных ветвей создаются абстракции процессов, а позже и потоков. Простейший случай параллелизма – когда N (N>1) задач разделяют между собой ресурсы: время единого процессора, общий объем физической оперативной памяти…

Но многозадачное разделение времени – не единственный случай практической реализации параллельных вычислений. В общем случае программа может выполняться в аппаратной архитектуре, содержащей более одного (M) процессора (SMP-системы). При этом возможны принципиально отличающиеся по поведению ситуации:

• Количество параллельных ветвей (процессов, потоков) N больше числа процессоров M, при этом некоторые вычислительные ветви находятся в блокированных состояниях, конкурируя с выполняющимися ветвями за процессорное время. (Частный случай – наиболее часто имеющее место выполнение N ветвей на одном процессоре.)

• Количество параллельных ветвей (процессов, потоков) N меньше числа процессоров M, при этом все ветви вычисления могут развиваться действительно параллельно, а блокированные состояния возникают только при необходимости синхронизации и обмена данными между параллельными ветвями.

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


[Закрыть]Так, в программном фрагменте:

void* threadfunc(void* data) {

 // оператор 1:

}

...

pthread_create(NULL, NULL, threadfunc, NULL);

// оператор 2:

...

нельзя допускать никаких априорных предположений о том, как пойдет дальнейшее выполнение после точки ветвления (точки вызова pthread_create()): а) будет выполняться «оператор 2» в родительском потоке; б) будет выполняться «оператор 1» в порожденном потоке; в) на различных процессорах будут действительно одновременно выполняться «оператор 1» и «оператор 2»… Программный код должен быть организован так, чтобы в любых аппаратных конфигурациях (количество процессоров, их скорости, особенности кэширования памяти процессорами и другие характеристики) результаты выполнения были полностью эквивалентны.

Благодаря наличию в составе ОС QNX сетевой подсистемы QNET, органично обеспечивающей «прозрачную» интеграцию сетевых узлов в единую многомашинную систему, возникает дополнительный источник параллелизма (а вместе с тем и дополнительных хлопот), еще более усложняющий общую картину: запросы по QNET к сервисам, работающим на одном сетевом узле, со стороны клиентских приложений, работающих на других. Например, ежедневно выполняя простейшую команду:

# cp /net/host/dev/ser1 ./file

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

Для текущей выполняющейся задачи такой удаленный запрос из сети QNET является скрытым источником параллелизма, а благодаря наследованию приоритетов даже удаленный запрос по сети может привести к немедленному вытеснению локальной задачи, выполняющейся до получения запроса.

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

Как уже неоднократно отмечалось, параллельная техника выражения в программном коде, пусть даже принципиально последовательных процессов, сопряжена с определенными трудностями: необходимость отличного, «параллельного», взгляда на описываемые процессы и отсутствие привычки применять специфические разделы API, редко используемые в классическом «последовательном» программировании. Единожды освоив эту технику, применять ее в дальнейшем становится легко и просто. Возможно и большее число рутинных приемов использования параллельной техники – в своей книге мы постарались «рассыпать» по тексту множество программных иллюстраций.

Наконец, есть еще одна, последняя особенность предлагаемого вашему вниманию материала: значительная часть приводимых здесь примеров и описаний относится ко всему многообразию ОС, поддерживающих POSIX-стандарт, однако акцент делается на не совсем очевидные особенности построения так называемых «приложений реального времени» [4]. В первую очередь это касается принципов синхронизации задач, совместно использующих общий ресурс. К сожалению, приемы программирования, широко распространенные при параллельном выполнении задач общего назначения, могут привести к не совсем предсказуемым результатам (по времени реакции) при построении систем реального времени. Особенности построения параллельно исполняемых систем в сферах реального времени и стали тем ключевым моментом, ориентируясь на который мы строили этот текст.