Программирование для Linux. Профессиональный подход

Митчелл Марк

Оулдем Джеффри

Самьюэл Алекс

Часть I

Сложные вопросы программирования в среде UNIX/Linux

 

 

Глава 1

Начало

 

В этой главе рассказывается о том, как выполнять базовые операции, связанные с написанием программы на языке С или C++ в среде Linux. В частности, описываются процессы создания и модифицирования исходного текста на C/C++, компиляции этого текста и отладки полученного результата. Те, кто уже знакомы с программированием в Linux, могут смело переходить к главе 2, "Написание качественных программ для среды GNU/Linux".

При изложении материала всей книги мы предполагаем, что читатели знакомы с языком программирования С и C++ и наиболее распространенными функциями стандартной библиотеки языка С. Тексты программ в книге написаны на С, за исключением случаев, когда рассматривается конкретная особенность программирования на C++. Мы также предполагаем, что читатели умеют выполнять базовые операции в интерпретаторе команд Linux, в частности создавать каталоги и копировать файлы. В связи с тем что многие Linux-программисты начинали свой путь в среде Windows, мы иногда будем указывать на сходства и различия между двумя операционными системами.

 

1.1. Редактор Emacs

 

Редактор — это программа, используемая для модификации исходных текстов. В Linux множество редакторов, но, очевидно, наиболее популярный и многофункциональный среди них — GNU Emacs.

Несколько слов о Emacs

Emacs — нечто гораздо большее, чем просто редактор. Это необычайно мощная программа, работая в которой можно, к примеру, читать и отправлять электронные сообщения. Способы настройки и расширения ее функциональных возможностей столь обширны, что заслуживают написания отдельной книги. Представьте, что, находясь в Emacs, вы можете путешествовать в Internet!

Впрочем, мы не ограничиваем свободу читателей, привыкших работать в другом редакторе. Ни один из примеров книги не зависит от использования Emacs. Представленный ниже небольшой вводный курс предназначен для тех из вас, кто еще не успел выбрать свой любимый редактор в Linux.

 

1.1.1. Открытие исходного файла C/C++

Чтобы запустить редактор Emacs, наберите emacs в окне терминала и нажмите . Появится окно редактора, в верхней части которого имеется строка меню. Перейдите в меню Files, выберите команду Open Files и наберите имя требуемого файла в строке "мини-буфера" в нижней части экрана. При создании исходного файла на языке С используйте расширения .с или .h. В случае C++ придерживайтесь расширений .cpp, .hpp, .С или .H. Когда файл будет открыт, введите нужный текст и сохраните результат, выбрав команду Save Buffer в меню Files. Чтобы выйти из редактора, воспользуйтесь командой Exit Emacs в меню Files.

Те, кто испытывают раздражение от необходимости постоянно щелкать мышью, могут воспользоваться клавиатурными сокращениями, ускоряющими открытие и сохранение файлов, а также выход из редактора. Операции открытия файла соответствует сокращение C-x C-f. (Запись C-x означает нажатие клавиши с последующим нажатием клавиши .) Чтобы сохранить файл, введите C-x C-s, а чтобы выйти из Emacs — C-x C-c. Лучше узнать о возможностях редактора можно с помощью встроенного учебника, доступного через команду Emacs Tutorial в меню Help. В нем приведено множество советов, которые помогут пользователям научиться эффективнее работать с Emacs.

 

1.1.2. Автоматическое форматирование

Программисты, привыкшие работать в интегрированной среде разработки, оценят имеющиеся в Emacs средства автоматического форматирования кода. При открытии исходного файла, написанного на C/C++, редактор самостоятельно определяет наличие в нем программного кода, а не просто текста. Если нажать клавишу в пустой строке, редактор переместит курсор в нужную позицию, определяемую положением предыдущей строки. Когда клавиша нажимается в строке, содержащей какой-то текст, сдвигается вся строка. Предположим, к примеру, что набран такой текст:

int main() {

printf("Hello, world\n");

}

Нажатие клавиши в строке вызова функции printf() приведет к следующему результату:

int main() {

  printf("Hello, world\n");

}

По мере работы с редактором Emacs читатели изучат и другие средства форматирования. Особенность редактора заключается в том. что он позволяет программировать практически любые операции, связанные с автоматическим форматированием. Благодаря этому были реализованы режимы редактирования множества видов документов, разработаны игры и даже СУБД.

 

1.1.3. Синтаксические выделения

Помимо форматирования программного кода Emacs упрощает чтение файлов, написанных на C/C++, выделяя цветом различные синтаксические элементы. Например, ключевые слова могут быть выделены одним цветом, названия встроенных типов данных — другим, а комментарии — третьим. Подобный подход облегчает нахождение некоторых широко распространенных синтаксических ошибок.

Чтобы включить режим цветовых выделений, откройте файл ~/.emacs и вставьте в него такую строку:

(global-font-lock-mode t)

Сохраните файл, выйдите из Emacs и перезапустите редактор. Теперь можете открыть нужный исходный файл и наслаждаться!

Внимательные читатели, возможно, обратили внимание на то, что строка, вставленная в файл .emacs, выглядит написанной на языке LISP. Это и есть LISP! Большая часть редактора Emacs реализована именно на этом языке. На нем же можно писать расширения к редактору.

 

1.2. Компиляторы GCC

 

Компилятор превращает исходный текст программы, понятный человеку, в объектный код. исполняемый компьютером. Компиляторы, доступные в Linux-системах, являются честью коллекции GNU-компиляторов, известной как GCC (GNU Compiler Collection). В нее входят компиляторы языков С, C++, Java, Objective-C, Fortran и Chill. В этой книге нас будут интересовать лишь первые два.

Предположим, имеется проект, в который входят два исходных файла: один написан на С (main.c; листинг 1.1), а другой — на C++ (reciprocal.cpp; листинг 1.2). После компиляции оба файла компонуются вместе, образуя программу reciprocal, которая вычисляет обратное заданного целого числа.

Листинг 1.1. ( main.c ) Исходный файл на языке С

#include

#include "reciprocal.hpp"

int main(int argc, char **argv) {

 int i;

 i = atoi(argv[1]);

 printf("The reciprocal of %d is %g\n", i, reciprocal(i));

 return 0;

}

Листинг 1.2. ( reciprocal.cpp ) Исходный файл на языке C++

#include

#include "reciprocal.hpp"

double reciprocal (int i) {

 // Аргумент не должен быть равен нулю

 assert(i != 0);

 return 1.0/i;

}

Есть также файл заголовков, который называется reciprocal.hpp (листинг 1.3).

Листинг 1.3. ( reciprocal.hpp ) Файл заголовков

#ifdef __cplusplus

extern "С" {

#endif

extern double reciprocal(int i);

#ifdef __cplusplus

}

#endif

Первый шаг заключается в превращении исходных файлов в объектный код.

 

1.2.1. Компиляция одного исходного файла

Компилятор языка С называется gcc. При компиляции исходного файла нужно указывать опцию -с. Вот как, например, в режиме командной строки компилируется файл main.с:

% gcc -с main.с

Полученный объектный файл будет называться main.o.

Компилятор языка C++ называется g++. Он работает почти так же, как и gcc. Следующая команда предназначена для компиляции файла reciprocal.cpp:

% g++ -c reciprocal.cpp

Опция -с говорит компилятору о необходимости получить на выходе объектный файл (он будет называться reciprocal.o). Без неё компилятор g++ попытается скомпоновать программу и создать исполняемый файл.

В процессе написания любой более-менее крупной программы обычно задействуется ряд дополнительных опций. К примеру, опция -I сообщает компилятору о том, где искать файлы заголовков. По умолчанию компиляторы GCC просматривают текущий каталог, а также каталоги, где установлены файлы стандартных библиотек. Предположим, наш проект состоит из двух каталогов: src и include. Следующая команда даст компилятору g++ указание дополнительно искать файл reciprocal.hpp в каталоге ../include :

% g++ -с -I ../include reciprocal.cpp

Иногда требуется задать макроконстанты в командной строке. Например, в коммерческой версии программы нет необходимости осуществлять избыточную проверку утверждения в файле reciprocal.cpp; она нужна лишь в целях отладки. Эта проверка отключается путем определения макроконстанты NDEBUG. Можно, конечно, явно добавить в файл директиву #define, но это означает изменение исходного текста программы. Проще сделать то же самое в командной строке:

% g++ -c -D NDEBUG reciprocal.cpp

Аналогичным образом можно задать конкретный уровень отладки:

% g++ -с -D NDEBUG=3 reciprocal.cpp

При написании коммерческих программ оказываются полезными средства оптимизации кода, имеющиеся в компиляторах GCC. Есть несколько уровней оптимизации; для большинства программ подходит второй. Следующая команда компилирует файл reciprocal.cpp с включенным режимом оптимизации второго уровня:

% g++ -с -O2 reciprocal.cpp

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

Компиляторы gcc и g++ принимают множество различных опций. Получить их полный список можно в интерактивной документации. Для этого введите следующую команду:

% info gcc

 

1.2.2. Компоновка объектных файлов

После того как файлы main.c и reciprocal.cpp скомпилированы, необходимо скомпоновать их. Если в проект входит хотя бы один файл C++, компоновка всегда осуществляется с помощью компилятора g++. Если же все файлы написаны на языке С, нужно использовать компилятор gcc. В нашем случае имеются файлы обоих типов, поэтому требуемая команда выглядит так:

% g++ -о reciprocal main.o reciprocal.o

Опция -о задает имя файла, создаваемого в процессе компоновки. Теперь можно осуществить запуск программы reciprocal:

% ./reciprocal 7

The reciprocal of 7 is 0.142857

Как видите, компилятор g++ автоматически подключил к проекту стандартную библиотеку языка С, содержащую реализацию функции printf(). Для компоновки дополнительных библиотек (например, модуля функций графического интерфейса пользователя) необходимо воспользоваться опцией -l. В Linux имена библиотек почти всегда начинаются с префикса lib. Например, файл подключаемого модуля аутентификации (Pluggable Authentication Module, РАМ) называется libpam.a. Чтобы скомпоновать его с имеющимися файлами, введите такую команду:

% g++ -о reciprocal main.o reciprocal.o -lpam

Компилятор автоматически добавит к имени библиотеки префикс lib и суффикс .a.

Как и в случае с файлами заголовков, компилятор ищет библиотечные файлы в стандартных каталогах, в частности /lib и /usr/lib. Для задания дополнительных каталогов предназначена опция -L, которая аналогична рассматривавшейся выше опции -I. Следующая команда сообщает компоновщику о том, что поиск библиотечных файлов нужно осуществлять прежде всего в каталоге /usr/local/lib/pam:

% g++ -o reciprocal main.o reciprocal.o -L/usr/local/lib/pam -lpam

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

% gcc -o app app.o -L. -ltest

 

1.3. Автоматизация процесса с помощью GNU-утилиты make

Те, кто программируют в Windows, привыкли работать в той или иной интегрированной среде разработки. Программист добавляет в нее исходные файлы, а среда автоматически создает проект. Аналогичные среды доступны и в Linux, но мы не будем рассматривать их. Вместо этого мы научим читателей работать с GNU-утилитой make, знакомой большинству Linux-программистов. Она позволяет автоматически перекомпилировать программу.

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

В нашем тестовом проекте reciprocal три очевидных целевых модуля: reciprocal.o, main.o и сама программа reciprocal. Правила нам уже известны: это рассмотренные выше командные строки. А вот над зависимостями нужно немного подумать. Ясно, что файл reciprocal зависит от файлов reciprocal.o и main.o, поскольку нельзя скомпоновать программу, не создав оба объектных файла. Последние должны перестраиваться при изменении соответствующих исходных файлов. Нельзя также забывать о файле reciprocal.hpp: он включается в оба исходных файла, поэтому его изменение тоже затрагивает объектные файлы.

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

Чтобы передать всю эту информацию утилите make, необходимо создать файл Makefile. Его содержимое будет таким:

reciprocal: main.o reciprocal.o

       g++ $(CFLAGS) -о reciprocal main.o reciprocal.o

main.o: main.c reciprocal.hpp

        gcc $(CFLAGS) -c main.c

reciprocal.o: reciprocal.cpp reciprocal.hpp

        g++ $(CFLAGS) -c reciprocal.cpp

clean:

        rm -f *.o reciprocal

Целевые модули перечислены слева. За именем модуля следует двоеточие и существующие зависимости. В следующей строке указано правило, по которому создается модуль (назначение записи $(CFLAGS) мы пока проигнорируем). Строка правила должна начинаться с символа табуляции, иначе утилита make проинтерпретирует ее неправильно.

Если удалить созданные нами выше объектные файлы и ввести

% make

будет получен следующий результат:

% make

gcc -c main.c

g++ -c reciprocal.cpp

g++ -o reciprocal main.o reciprocal.o

Утилита make автоматически создала объектные файлы и скомпоновала их. Попробуйте теперь внести какое-нибудь простейшее изменение в файл main.c и снова запустить утилиту. Вот что произойдет:

% make

gcc -с main.c

g++ -о reciprocal main.o reciprocal.o

Как видите, утилита make повторно создала файл main.o и перекомпоновала программу, но не стала перекомпилировать файл reciprocal.cpp, так как в этом не было необходимости.

Запись $(CFLAGS) обозначает переменную утилиты make. Ее можно определить либо в файле Makefile, либо в командной строке. Утилита подставит на место переменной реальное значение во время выполнения правила. Вот как, например, можно осуществить перекомпиляцию с включённой оптимизацией:

% make clean

rm -f *.o reciprocal

% make CFLAGS=-O2

gcc -O2 -c main.c

g++ -O2 -c reciprocal.cpp

g++ -O2 -o reciprocal main.o reciprocal.o

Обратите внимание на то, что вместо записи $(CFLAGS) в правилах появился флаг -O2.

В этом разделе мы рассмотрели лишь самые основные возможности утилиты make. Чтобы получить о ней более подробную информацию, обратитесь к интерактивной документации, введя такую команду:

% info make

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

 

1.4. GNU-отладчик gdb

 

Отладчик — это программа, с помощью которой можно узнать, почему написанная вами программа ведет себя не так, как было задумано. Работать с отладчиком приходится очень часто. Большинство Linux-программистов имеет дело с GNU-отладчиком (GNU Debugger, GDB), который позволяет пошагово выполнять программу, создавать точки останова и проверять значения локальных переменных.

 

1.4.1. Компиляция с включением отладочной информации

Чтобы можно было воспользоваться GNU-отладчиком, необходимо скомпилировать программу с включением в нее отладочной информации. Этой цели служит опция -g компилятора. Если имеется описанный выше файл Makefile, достаточно задать переменную CFLAGS равной -g при запуске утилиты make:

% make CFLAGS=-g

gcc -g -с main.c

g++ -g -c reciprocal.cpp

g++ -g -о reciprocal main.o reciprocal.o

Встречая в командной строке флаг -g, компилятор включает дополнительную информацию в объектные и исполняемые файлы. Благодаря этой информации отладчик узнает, какие адреса соответствуют тем или иным строкам в том или ином исходном файле, как отобразить значение локальной переменной, и т.д.

 

1.4.2. Запуск отладчика

Отладчик gdb запускается следующим образом:

% gdb reciprocal

После запуска появится строка приглашения такого вида:

(gdb)

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

(gdb) run

Starting program: reciprocal

Program received signal SIGSEGV, Segmentation fault.

__strtol_internal (nptr=0x0, endptr=0x0, base=10, group=0)

at strtol.c:287

287  strtol.c: No such file or directory.

(gdb)

Проблема заключается в том, что в функции main() не предусмотрены средства контроля ошибок. Программа ожидает наличия аргумента, а в данном случае его нет. Получение сигнала SIGSEGV означает крах программы. Отладчик определяет, что причина краха находится в функции __strtol_internal(). Эта функция является частью стандартной библиотеки, но ее исходный файл отсутствует. Вот почему появляется сообщение "No such file or directory". С помощью команды where можно просмотреть содержимое стека:

(gdb) where

#0 __strtol_internal (nptr=0x0, endptr=0x0, base=10, group=0)

   at strtol.c:287

#1 0x40096fb6 in atoi (nptr=0x0) at ../stdlib/stdlib.h:251

#2 0x804863e in main (argc=1, argv=0xbffff5e4) at main.c:8

Как нетрудно заметить, функция main() вызвала функцию atoi(), передав ей нулевой указатель, что и стало причиной ошибки.

С помощью команды up можно подняться но стеку на два уровня, дойдя до функции main():

(gdb) up 2

#2 0x804863е in main (argc=1, argv=0xbffff5e4) at main.c:8

8    i = atoi(argv[1]);

Заметьте, что отладчик нашел исходный файл main.c и отобразил строку, где располагается ошибочный вызов функции. Узнать значение нужной локальной переменной позволяет команда print:

(gdb) print argv[1]

$2 = 0x0

Это подтверждает нашу догадку о том, что причина ошибки — передача функции atoi() указателя NULL.

Установка контрольной точки осуществляется посредством команды break:

(gdb) break main

Breakpoint 1 at 0x804862e: file main.c, line 8.

В данном случае контрольная точка размещена в первой строке функции main(). Давайте теперь заново запустим программу, передав ей один аргумент:

(gdb) run 7

Starting program: reciprocal 7

Breakpoint 1, main (argc=2, argv=0xbffff5e4) at main.c:8

8   i = atoi(argv[1]);

Как видите, отладчик остановился на контрольной точке- Перейти на следующую строку можно с помощью команды next:

(gdb) next

9    printf("The reciprocal of %d is %g\n", i,

reciprocal(i));

Если требуется узнать, что происходит внутри функции reciprocal(), воспользуйтесь командой step:

(gdb) step

reciprocal (i=7) at reciprocal.cpp:6

6    assert(i != 0);

Иногда удобнее запускать отладчик gdb непосредственно из редактора Emacs, а не из командной строки. Для этого следует ввести в редакторе команду M-x gdb. Когда отладчик останавливается в контрольной точке, редактор Emacs автоматически открывает соответствующий исходный файл. Не правда ли. проще разобраться в происходящем, глядя на весь файл, а не на одну его строку?

 

1.5. Поиск дополнительной информации

 

В каждый дистрибутив Linux входит масса полезной документации. В ней можно прочесть почти все из того, о чем говорится в этой книге (хотя это, очевидно, займет больше времени). Документация не всегда хорошо организована, поэтому поиск нужной информации требует определенной изобретательности. Иногда представленные факты оказываются устаревшими, так что не стоит всему слепо верить.

Ниже описаны наиболее полезные источники информации о программировании в Linux.

 

1.5.1. Интерактивная документация

В дистрибутивы Linux входят man-страницы с описанием большинства стандартных команд, системных вызовов и стандартных библиотечных функций. Интерактивная документация разбита на разделы, которым присвоены номера. Для программистов наиболее важными являются следующие разделы:

(1) пользовательские команды;

(2) системные вызовы:

(3) стандартные библиотечные функции:

(8) системные/административные команды.

Числа обозначают номера разделов. Для доступа к страницам интерактивной документации применяется команда man. Она имеет вид man имя , где имя — название команды или функции. Иногда одно и то же имя встречается в разных разделах. В этом случае номер раздела нужно указать явно, поставив его перед именем. К примеру, так вызывается страница с описанием команды sleep (находящаяся в первом разделе):

% man sleep

А следующая команда вызывает страницу с описанием библиотечной функции sleep():

% man 3 sleep

Каждая man-страница содержит однострочное резюме команды или функции. Команда whatis имя отображает список всех man-страниц (во всех разделах), связанных с указанным именем. Если не известно точно, описание какой команды или функции требуется, можно выполнить поиск по ключевому слову в строках резюме с помощью команды man -k ключевое_слово .

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

 

1.5.2. Система Info

Система Info содержит гораздо более подробную документацию ко многим базовым компонентам GNU/Linux, а также к ряду других программ. Информационные страницы представляют собой гипертекстовые документы, напоминающие Web-страницы. Для запуска текстовой версии справочной системы Info достаточно ввести info в командной строке. Появится меню с описанием иерархии документов, установленных в системе. Нажав , можно получить список клавиш, посредством которых осуществляется навигация по документам системы Info.

Среди наиболее полезных документов перечислим следующие:

■ gcc — описание компилятора gcc;

■ libc — описание GNU-библиотеки языка С, содержащей множество системных вызовов,

■ gdb — описание GNU-отладчика;

■ emacs — описание редактора Emacs;

■ info — описание самой системы Info.

Можно сразу вызвать нужную страницу, задав ее имя в командной строке:

% info libs

Те, кто в основном работают в Emacs, могут вызвать встроенный модуль просмотра документов Info, набрав M-x info или C-h i.

 

1.5.3. Файлы заголовков

Много информации о системных функциях можно почерпнуть из системных файлов заголовков. Они находятся в каталогах /usr/include и /usr/include/sys. Например, если компилятор сообщает об ошибке вызова системной функции, загляните в соответствующий файл заголовков и убедитесь, что реальный прототип функции соответствует описанному на man-страннце.

В Linux множество деталей функционирования системных вызовов отражено в файлах заголовков расположенных в каталогах /usr/include/bits, /usr/include/asm и /usr/include/linux. В частности, номера сигналов (механизм сигналов рассматривается в разделе 3.3, "Сигналы") определены в файле /usr/include/bits/signum.h.

 

1.5.4. Исходные тексты

Linux — система с открытым кодом, не так ли? Верховным судьей, определяющим, как работает система, является исходный код самой системы. К нашему счастью, он доступен бесплатно. В имеющийся дистрибутив Linux могут входить исходные тексты всей системы и всех установленных в ней программ. (Правда, они не всегда записываются на жесткий диск. Инструкции по инсталляции исходных текстов содержатся в документации дистрибутива.) Если это не так, у вас есть право запросить их на основании общей открытой GNU-лицензии.

Исходный код ядра Linux обычно хранится в каталоге /usr/src/linux. Это хороший источник информации о том, как работают процессы, виртуальная память и системные устройства. Большинство системных функций, упоминаемых в книге, реализовано в GNU- библиотеке языка С. Местоположение ее исходных текстов можно узнать в документации к дистрибутиву.

 

Глава 2

Написание качественных программ для среды GNU/Linux

 

В этой главе описываются базовые методики, применяемые большинством Linux-программистов. Придерживаясь данных методик, читатели смогут писать программы, которые не только хорошо работают а среде GNU/Linux, но и соответствуют представлениям пользователей о том, как должны работать такие программы.

 

2.1. Взаимодействие со средой выполнения

 

Те, кто изучали языки С и C++, знают, что специальная функция main() является главной точкой входа в программу. Когда операционная система запускает программу на выполнение, она автоматически предоставляет определенные средства, позволяющие программе взаимодействовать как с самой системой, так и с пользователем. Читатели наверняка знают о том, что у функции main() есть два параметра, argc и argv, через которые в программу передаются входные данные. Имеются также стандартные потоки stdout и stdin (или cout и cin в C++), реализующие консольный ввод-вывод. Все эти элементы существуют в языках С и C++, и работа с ними в среде GNU/Linux происходит строго определенным образом.

 

2.1.1. Список аргументов

Для запуска программы достаточно ввести ее имя в командной строке. Дополнительные информационные элементы, передаваемые программе, также задаются в командной строке и отделяются от имени программы и друг от друга пробелами. Такие элементы называются аргументами командной строки. (Аргумент, содержащий пробел, должен заключаться в кавычки.) Вообще-то, если быть более точным, правильнее говорить о списке аргументов, поскольку они не обязательно поступают из командной строки. В главе 3, "Процессы", рассказывается об ином способе вызова программы, при котором другая программа может передавать ей список аргументов напрямую.

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

% ls -s /

В данном случае список аргументов программы ls состоит из трех элементов. Первый — это имя самой программы, указанное в командной строке, а именно ls. Второй и третий элементы — аргументы командной строки -s и /.

Функция main() получает доступ к списку аргументов благодаря своим параметрам argc и argv (если они не используются, их можно не указывать). Параметр argc — это целое число, равное количеству элементов в списке. Параметр argv — это массив символьных указателей. Размер массива равен argc, а каждый элемент массива указывает на соответствующий элемент списка. Все аргументы представляются в виде строк, оканчивающихся нулевым символом.

Работа с аргументами командной строки сводится к просмотру параметров argc и argv. Если имя программы не должно учитываться, не забудьте пропустить первый элемент списка.

Использование параметров argc и argv демонстрируется в листинге 2.1.

Листинг 2.1. ( arglist.c ) Использование параметров argc и argv

#include

int main (int argc, char* argv[]) {

 printf("The name of this program is "%s*.\n", argv[0]);

 printf("This program was invoked with %d arguments.\n", argc - 1);

 /* Имеется ли хоть один аргумент? */

 if (argc > 1) {

  /* Да; отображаем содержимое. */

  int i;

  printf("The arguments are:\n");

  for (i = 1; i < argc; ++i)

   printf(" %s\n", argv[i]);

 }

 return 0;

}

 

2.1.2. Соглашения по работе с командной строкой в GNU/Linux

Практически все Linux-программы подчиняются соглашениям об интерпретации аргументов командной строки. Аргументы подразделяются на две категории: опции (или флаги) и все остальные. Опции меняют поведение программы, а остальные аргументы содержат разного рода входные данные (например, названия входных файлов).

Опции бывают двух видов.

■ Короткие опции состоят из дефиса и одиночного символа (обычно это буква в нижнем или верхнем регистре). Такие опции быстрее и проще набирать.

■ Длинные опции состоят из двух дефисов, после которых следует имя. содержащее буквы нижнего и верхнего регистров и дефисы. Такие опции легче запоминать и читать (например, в командных сценариях).

Обычно программа поддерживает обе разновидности каждой опции: первую — для краткости, вторую — для ясности. Например, большинство программ понимает опции -h и --help и трактует их одинаково. Как правило, опции указываются сразу после имени программы. После опций могут идти другие аргументы, в частности имена входных файлов и входные данные.

Некоторые опции предполагают наличие собственных аргументов. Так, рассмотренная выше команда ls -s / выводит содержимое корневого каталога. Опция -s сообщает программе ls о необходимости отображения размера (в килобайтах) каждого элемента каталога. Аргумент / задает имя каталога. Опция --size является синонимом опции -s, поэтому та же самая команда может быть задана так: ls -- size /.

В документе GNU Coding Standards перечислены имена некоторых наиболее часто используемых опций командной строки. При написании GNU-программ рекомендуется сверяться с этим документом. Пользователям удобно работать с программами, у которых много общих черт. Получить доступ к упомянутому документу в большинстве Linux-систем позволяет команда

% info "(standards)User Interfaces"

 

2.1.3. Функция getopt_long()

Синтаксический анализ аргументов командной строки — утомительная задача. К счастью. в GNU-библиотеке языка С есть функция getopt_long(), упрощающая ее решение. Эта функция понимает как короткие, так и длинные опции. Ее объявление находится в файле .

Предположим, требуется написать программу, которая поддерживает три опции (табл. 2.1).

Таблица 2.1. Опции тестовой программы

Короткая форма Длинная форма Назначение
-h --help Отображение справки по использованию программы и выход
-o имя_файла --output имя_файла Задание имени выходного файла
-v --verbose Отображение развернутых сообщений

Кроме того, программе могут быть переданы дополнительные аргументы, задающие имена входных файлов

Функции getopt_long() нужно передать две структуры. Первая — это строка с описанием возможных коротких опций (каждая из них представлена одной буквой). Если опция предполагает наличие аргумента, после нее ставится двоеточие. В нашем случае строка будет иметь вид ho:v. Это говорит о том, что программа поддерживает опции -h, -о и -v, причем для второй из них требуется аргумент.

Список возможных длинных опций задается в виде массива структур option. Каждый элемент массива соответствует одной опции и состоит из четырех полей. Чаще всего первое поле содержит имя опции (строка символов без ведущих дефисов), второе  — 1, если опция принимает аргумент, и 0 — в противном случае: третье — NULL; четвертое — символьная константа, задающая короткий эквивалент данной длинной опции. Последний элемент массива должен содержать одни нули. Наш массив будет выглядеть так:

const struct option long_options[] = {

 { "help",    0, NULL, 'h' },

 { "output",  1, NULL, 'o' },

 { "verbose", 0, NULL, 'v' },

 { NULL,      0, NULL, 0 }

};

Функции getopt_long() передаются также параметры argc и argv функции main(). Ниже перечислены особенности ее работы.

■ При каждом вызове функция getopt_long() анализирует очередную опцию, возвращая букву, которая соответствует короткому эквиваленту опции. При отсутствии опций возвращается -1.

■ Обычно функция getopt_long() вызывается в цикле для обработки всех опций командной строки. Выбор конкретной опции осуществляется посредством конструкции switch.

■ Если опция getopt_long() обнаруживает неправильную опцию (т.е. она не указана в списке коротких и длинных опций), она выводит сообщение об ошибке и возвращает символ ? (знак вопроса). В ответ на это большинство программ завершает свою работу, обычно отображая справку по работе с программой.

■ При обработке опции, имеющей аргумент, в глобальную переменную optarg помещается указатель на строку с содержимым аргумента.

■ Когда функция getopt_long() завершает анализ опций, в глобальную переменную optind записывается индекс того элемента массива argv, в котором содержится первый аргумент, не являющийся опцией.

В листинге 2.2 приведен пример обработки аргументов программы с помощью функции getopt_long().

Листинг 2.2. ( getopt_long.c ) Использование функции getopt_long()

#include

#include

#include

/* Имя программы. */

const char* program_name;

/* Вывод информации об использовании программы в поток STREAM

   (обычно stdout или stderr) и завершение работы с выдачей кода

   EXIT_CODE. Возврат в функцию main() не происходит */

void print_usage(FILE* stream, int exit_code) {

 fprintf(stream, "Usage: %s options [ inputfile ... ]\n",

  program_name);

 fprintf(stream,

  " -h --help    Display this usage

                 information.\n"

  " -о --output  filename Write output to file.\n"

  " -v --verbose Print verbose messages.\n");

 exit(exit_code);

}

/* Точка входа в основную программу, параметр ARGC содержит размер

   списка аргументов; параметр ARGV -- это массив указателей

   на аргументы. */

int main(int argc, char* argv[]) (

 int next_option;

 /* Строка с описанием возможных коротких опций. */

 const char* const short_options = "ho:v";

 /* Массив с описанием возможных длинных опций. */

 const struct option long_options[] = {

  { "help",    0, NULL, 'h' },

  { "output",  1, NULL, 'o' },

  { "verbose", 0, NULL, 'v' },

  { NULL,      0, NULL, 0 } /* Требуется в конце массива. */

 };

 /* Имя файла, в который записываются результаты работы

    программы, или NULL, если вывод направляется в поток

    stdout. */

 const char* output_filename = NULL;

 /* Следует ли выводить развернутые сообщения. */

 int verbose = 0;

 /* Запоминаем имя программы, которое будет включаться

    в сообщения. Оно хранится в элементе argv[0] */

 program_name = argv[0];

 do {

  next_option =

   getopt_long(argc, argv, short_options,

    long_options, NULL);

  switch(next_opt ion) {

  case "h": /* -h или --help */

   /* Пользователь запросил информацию об использовании

      программы, нужно вывести ее в поток stdout и завершить

      работу с выдачей кода 0 (нормальное завершение). */

   print_usage(stdout, 0);

  case 'o': /* -о или --output */

   /* Эта опция принимает аргумент -- имя выходного файла. */

      output_filename = optarg;

   break;

  case 'v': /* -v или --verbose */

   verbose = 1;

   break;

  case '?': /* Пользователь ввел неверную опцию. */

   /* Записываем информацию об использовании программы в поток

      stderr и завершаем работу с выдачей кода 1

      (аварийное завершение). */

   print_usage(stderr, 1);

  case -1: /* Опций больше нет. */

   break;

  default: /* Какой-то непредвиденный результат. */

   abort();

  }

 }

 while (next_option != -1);

 /* Обработка опций завершена, переменная OPTIND указывает на

    первый аргумент, не являющийся опцией. В демонстрационных

    целях отображаем эти аргументы, если задан режим VERBOSE. */

 if (verbose) {

  int i;

  for (i = optind; i < argc; ++i)

   printf("Argument: %s\n", argv[i]);

 }

 /* Далее идет основное тело программы... */

 return 0;

}

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

 

2.1.4. Стандартный ввод-вывод

В стандартной библиотеке языка С определены готовые потоки ввода и вывода (stdin и stdout соответственно). Они используются функциями scanf(), printf() и целым рядом других библиотечных функций. Согласно идеологии UNIX, стандартные потоки можно перенаправлять. Это позволяет образовывать цепочки программ, связанных посредством каналов (конкретный синтаксис перенаправления потоков и работы с каналами можно узнать в документации к интерпретатору команд).

Есть также стандартный поток ошибок: stderr. Программы должны направлять предупреждающие сообщения и сообщения об ошибках в него, а не в поток stdout. Это позволяет отделять обычные выводные данные от разного рода служебных сообщений. К примеру, стандартный поток вывода можно направить в файл, а сообщения об ошибках, по-прежнему отображать на консоли. Запись в поток stderr осуществляется с помощью функции fprintf():

fprintf(stderr, ("Error: ..."));

Все три стандартных потока доступны низкоуровневым функциям ввода-вывода (read(), write() и т.д.) через дескрипторы файлов. В частности, поток stdin имеет дескриптор 0, stdout — 1, a stderr — 2.

При вызове программы иногда требуется одновременно перенаправить потоки вывода и ошибок в файл или канал. Синтаксис подобной операции зависит от используемого интерпретатора команд. В интерпретаторах семейства Bourne shell (включая bash, который по умолчанию установлен в большинстве дистрибутивов Linux) это делается так:

% program > output_file.txt 2>&1

% program 2>&1 | filter

Запись 2>&1 означает, что файл с дескриптором 2 (stderr) объединяется с файле имеющим дескриптор 1 (stdout). Обратите внимание на то, что эта запись должна идти после операции перенаправления в файл (первый пример), но перед операцией перенаправления в канал (второй пример).

Поток stdout является буферизуемым. Записываемые в него данные не посылаются на консоль (или на другое устройство в случае перенаправления), пока буфер не заполнится, программа не завершит работу нормальным способом или файл stdout не будет закрыт. Осуществить принудительное "выталкивание" буфера позволяет функция fflush():

fflush(stdout);

В то же время поток stderr не буферизуется. Записываемые в него данные сразу попадают на консоль.

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

while (1) {

 printf(".");

 sleep(1);

}

А в этом цикле происходит то, что нам нужно:

while (1) {

 fprintf(stderr, ".");

 sleep(1);

}

 

2.1.5. Коды завершения программы

Когда программа завершает работу, она уведомляет операционную систему о своем состоянии, посылая ей код завершения, который представляет собой 16-разрядное целое число. По существующему соглашению нулевой код свидетельствует об успешном завершении, а ненулевой указывает на наличие ошибки. Некоторые программы возвращают различные ненулевые коды, обозначая разные ситуации.

В большинстве интерпретаторов команд код завершения последней выполненной программы содержится в специальной переменной $?. В показанном ниже примере программа ls вызывается дважды, и оба раза запрашивается код ее завершения. В первом случае программа завершается корректно и возвращает нулевой код, во втором случае она сталкивается с ошибкой (указанный в командной строке файл не найден), поэтому код завершения оказывается ненулевым:

% ls /

bin  coda etc  lib        misc nfs proc sbin usr

boot dev  home lost+found mnt  opt root tmp  var

% echo $?

0

% ls bogusfile

ls: bogusfile: No such file or directory

% echo $?

1

Программа, написанная на языке С или C++, указывает код завершения в операторе return в функции main(). Есть и другие методы задания кодов завершения. Они обсуждаются в главе 3, "Процессы". Например, программе назначается определенный код, когда она завершается аварийно (вследствие получения сигнала).

 

2.1.6. Среда выполнения

Операционная система Linux предоставляет каждой запущенной программе среду выполнения. Под средой подразумевается совокупность пар переменная-значение. Имена переменных среды и их значения являются строками. По существующему соглашению переменные среды записываются прописными буквами.

Некоторые переменные должны быть знакомы большинству читателей, например:

■ USER — содержит имя текущего пользователя;

■ HOME — содержит путь к начальному каталогу текущего пользователя;

■ PATH — содержит разделенный двоеточиями список каталогов, которые операционная система просматривает в поиске вызванной программы;

■ DISPLAY — содержит имя и номер экрана сервера X Window, на котором отображаются окна графических программ.

Интерпретатор команд, как и любая другая программа, располагает своей средой. Имеются средства просмотра и редактирования переменных среды из командной строки. Например, программа printenv отображает текущую среду интерпретатора. В разных интерпретаторах есть свой встроенный синтаксис работы с переменными среды. Ниже демонстрируется синтаксис интерпретаторов семейства Bourne shell.

■ Интерпретатор автоматически создает локальную переменную (называемую переменной интерпретатора) для каждой обнаруживаемой им переменной среды. Благодаря этому возможен доступ к переменным среды через выражения вида $ переменная . Например:

% echo $USER

samuel

% echo $HOME

/home/samuel

■ С помощью команды export можно экспортировать переменную интерпретатора в переменную среды. Вот как, например, задается значение переменной EDITOR:

% EDITOR=emacs

% export EDITOR

Или короче:

% export EDITOR=emacs

В программе доступ к переменным среды осуществляет функция getenv(), объявленная в файле . В качестве аргумента она принимает имя переменной и возвращает се значение в строковом виде или NULL, если переменная не определена в данной среде. Для установки и сброса значений переменных среды предназначены функции setenv() и unsetenv() соответственно.

Получить список всех переменных среды немного сложнее. Для этого нужно обратиться к специальной глобальной переменной environ, определенной в GNU-библиотеке языка С. Данная переменная имеет тип char** и представляет собой массив указателей на символьные строки, последним элементом которого является NULL. Каждая строка имеет вид ПЕРЕМЕННАЯ = значение .

Программа, представленная в листинге 2.3, отображает всю свою среду, просматривая в цикле массив environ.

Листинг 2.3. ( print-env.c ) Вывод переменных среды

#include

/* Массив ENVIRON содержит среду выполнения. */

extern char** environ;

int main() {

 char** var;

 for (var = environ; *var != NULL; ++var)

  printf("%s\n", *var);

 return 0;

}

He пытайтесь модифицировать массив environ самостоятельно. Пользуйтесь для этих целей функциями setenv() и unsetenv().

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

Переменные среды чаще всего используют для передачи программам конфигурационной информации. Предположим, к примеру, что требуется написать программу, подключающуюся к серверу Internet. Имя сервера может задаваться в командной строке, но, если оно меняется нечасто, имеет смысл определить специальную переменную среды — скажем, SERVER_NAME, — которая будет хранить имя сервера. При отсутствии переменной программа берет имя, заданное по умолчанию. Интересующая нас часть программы показана в листинге 2.4.

Листинг 2.4. ( client.с ) Часть сетевой клиентской программы

#include

#include

int main() {

 char* server_name = getenv("SERVER_NAME");

 if (server_name == NULL)

  /* переменная среды SERVER_NAME не задана. Используем

     установки по умолчанию. */

  server_name = "server.my-company.com";

 printf("accessing server %s\n", server_name);

 /* Здесь осуществляется доступ к серверу... */

 return 0;

}

Допустим, программа называется client. Если переменная SERVER_NAME не задана, используется имя сервера, заданное по умолчанию:

% client

accessing server server.my-company.com

Вот как задается другой сервер:

% export SERVER_NAME=backup-server.elsewhere.net

% client

accessing server backup-server.elsewhere.net

 

2.1.7. Временные файлы

Иногда программе требуется создать временный файл, например для промежуточного хранения большого объема данных или для передачи данных другой программе. В системах GNU/Linux временные файлы хранятся в каталоге /tmp. Работая с временными файлами, необходимо помнить о следующих ловушках.

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

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

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

В Linux имеются функции mkstemp() и tmpfile(), решающие все вышеперечисленные проблемы. Выбор между ними делается на основании того, должен ли временный файл передаваться другой программе и какие функции ввода-вывода будут применяться при работе с файлом: низкоуровневые (read(), write() и т.д.) или потоковые (fopen(), fprintf() и т.д.).

Функция mkstemp()

Функция mkstemp() генерирует уникальное имя файла на основании переданного ей шаблона, создает временный файл с правами, разрешающими доступ к нему только для текущего пользователя, и открывает файл в режиме чтения/записи. Шаблон имени — это строка, оканчивающаяся последовательностью "XXXXXX" (шесть прописных букв "X"). Функция mkstemp() заменяет каждую букву произвольным символом таким образом, чтобы получилось уникальное имя, и возвращает дескриптор файла. Запись в файл осуществляется с помощью функций семейства write().

Временные файлы, создаваемые функцией mkstemp(), не удаляются автоматически. Ответственность за это возлагается на того, кто запускает программу. (Программисты должны внимательно следить за удалением временных файлов, иначе файловая система /tmp рано или поздно переполнится, приведя всю систему в нерабочее состояние.) Если файл создан для внутреннего использования и не предназначен для передачи другой программе, по окончании работы с ним нужно сразу же вызвать функцию unlink(). Она удаляет из каталога ссылку на файл, но сам файл остается до тех пор, пока не будут закрыты все ссылающиеся на него дескрипторы. Таким образом, программа может продолжать использовать временный файл; он будет удален автоматически сразу после закрытия дескриптора. Операционная система закрывает дескрипторы файлов по окончании работы программы, так что временный файл будет удален даже в случае аварийного завершения программы.

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

Листинг 2.5. ( temp_file.c ) Использование функции mkstemp()

#include

#include

/* дескриптор временного файла, созданного в функции

   write_temp_file(). */

typedef int temp_file_handle;

/* Запись указанного числа байтов из буфера во временный файл.

   Ссылка на временный файл немедленно удаляется. Возвращается

   дескриптор временного файла. */

temp_file_handle write_temp_file(char* buffer, size_t length) {

 /* Создание имени файла и самого файла. Цепочка XXXXXX будет

    заменена символами, которые сделают имя уникальным. */

 char temp_filename() = "/tmp/temp_file.XXXXXX";

 int fd = mkstemp(temp_filename);

 /* немедленное удаление ссылки на файл, благодаря чему он будет

    удален сразу же после закрытия дескриптора файла. */

 unlink(temp_filename);

 /* Сначала в файл записывается число, определяющее размер

    буфера. */

 write(fd, &length, sizeof(length));

 /* теперь записываем сами данные. */

 write(fd, buffer, length);

 /* Возвращаем дескриптор файла. */

 return fd;

}

/* Чтение содержимого временного файла, созданного в функции

   write_temp_file(). Создается и возвращается буфер с содержимым

   файла. Этот буфер должен быть удален в вызывающей подпрограмме

   с помощью функции free(). В параметр LENGTH записывается размер

   буфера в байтах. В конце временный файл удаляется. */

char* read_temp_file(temp_file_handle temp_file, size_t* length) {

 char* buffer;

 /* TEMP_FILE -- это дескриптор временного файла. */

 int fd = temp_file;

 /* переход в начало файла. */

 lseek(fd, 0, SEEK_SET);

 /* Определение объема данных, содержащихся во временном файле. */

 read(fd, length, sizeof(*length));

 /* Выделение буфера и чтение данных. */

 buffer = (char*)malloc(*length);

 read(fd, buffer, *length);

 /* Закрытие дескриптора файла, что приведет к уничтожению

    временного файла. */

 close(fd);

 return buffer;

}

Функция tmpfile()

Если в программе используются функции потокового ввода-вывода библиотеки языка С и передавать временный файл другой программе не нужно, то для работы с временным файлом больше подойдет функция tmpfile(). Она создает и открывает временный файл, возвращая файловый указатель на него. Ссылка на файл уже оказывается удаленной, благодаря чему он уничтожается автоматически при закрытии указателя (с помощью функции fclose()) или при завершении программы.

В Linux есть ряд других функций, предназначенных для генерирования временных файлов или их имен, в частности mktemp(), tmpnam() и tempnam(). Работать с ними нежелательно, поскольку возникают упоминавшиеся выше проблемы, связанные с надежностью и безопасностью.

 

2.2. Защита от ошибок

 

Написать программу, которая корректно работает при "разумном" использовании, — трудная задача. Написать программу, которая ведет себя "разумно" при возникновении ошибок, — еще труднее. В этом разделе описываются методики программирования, позволяющие выявлять ошибки на ранних стадиях и решать проблемы, возникающие в ходе выполнения программы.

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

 

2.2.1. Макрос assert()

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

Простейший способ выявления ненормальных ситуаций — стандартный макрос assert() в языке С. Его аргументом является булево выражение. Программа завершается, если выражение оказывается ложным, при этом выводится сообщение об ошибке с указанием исходного файла и номера строки, а также текста выражения, приведшего к ошибке. Макрос assert() оказывается очень полезным для самых разных проверок целостности, выполняемых внутри программы. Например, с помощью этого макроса проверяют правильность аргументов функций, выполнение входных и выходных условий при вызове функций (а также методов C++) и наличие непредвиденных возвращаемых значений.

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

В программах, критических к требованиям производительности, проверки assert() на этапе выполнения могут представлять собой слишком большую нагрузку. В таких случаях программа компилируется с установленной макроконстантой NDEBUG; для этого в командной строке компилятора указывается флаг -DNDEBUG. При наличии данной макроконстанты препроцессор убирает из тела программы все вызовы макроса assert(). И все же помните: делать это имеет смысл только тогда, когда производительность является узким местом программы, причем макрос нужно отключать лишь в наиболее критических файлах.

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

Предположим, к примеру, что в цикле вызывается функция do_something(). В случае успешного выполнения она возвращает 0, иначе — ненулевое значение. Легкомысленный программист считает, что функция всегда завершается успешно, поэтому возникает соблазн написать так:

for (i =0; i < 100; ++i)

 assert(do_something() == 0);

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

for (i = 0; i < 100; ++i) {

 int status = do_something();

 assert(status == 0);

}

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

Дадим несколько полезных советов.

■ Проверяйте наличие пустых указателей, например в списке аргументов функции. Сообщение об ошибке, генерируемое строкой {assert (pointer != NULL)},

Assertion 'pointer != ((void *)0)' failed.

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

Segmentation fault (core dumped)

■ Проверяйте значения параметров функции. Например, если в функции предполагается, что параметр foo имеет только положительные значения, поставьте следующую проверку в самом начале тела функции:

assert(foo > 0);

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

 

2.2.2. Ошибки системных вызовов

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

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

Сбои системных вызовов происходят в самых разных ситуациях.

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

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

■ Аргументы системного вызова могут оказаться неправильными либо по причине ошибочно введенных пользователем данных, либо из-за ошибки самой программы. Например, программа может передать системному вызову неправильный адрес памяти или неверный дескриптор файла. Другой вариант ошибки — попытка открыть каталог вместо обычного файла или передать имя файла системному вызову, ожидающему имя каталога.

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

■ Выполнение системного вызова иногда прерывается внешними событиями, к каковым относится, например, получение сигнала. Это не обязательно означает ошибку, но ответственность за перезапуск системного вызова возлагается на программу.

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

 

2.2.3. Коды ошибок системных вызовов

Большинство системных вызовов возвращает 0, если операция выполнена успешно, и ненулевое значение — в случае сбоя. (В некоторых случаях используются другие соглашения. Например, функция malloc() при возникновении ошибки возвращает нулевой указатель. Никогда не помешает прочесть man-страницу, посвященную требуемому системному вызову.) Обычно этой информации достаточно для того, чтобы решить, следует ли продолжать привычное выполнение программы. Но для более специализированной обработки ошибок необходимы дополнительные сведения.

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

Коды ошибок являются целыми числами. Возможные значения задаются макроконстантами препроцессора, которые, по существующему соглашению, записываются прописными буквами и начинаются с литеры "E", например EACCESS и EINVAL. При работе со значениями переменной errno следует всегда использовать макроконстанты, а не реальные числовые значения. Все эти константы определены в файле .

В Linux имеется удобная функция strerror(), возвращающая строковый эквивалент кода ошибки. Эти строки можно включать в сообщения об ошибках. Объявление функции находится в файле .

Есть также функция perror() (объявлена в файле ), записывающая сообщение об ошибке непосредственно в поток stderr. Перед собственно сообщением следует размещать строковый префикс, содержащий имя функции или модуля, ставших причиной сбоя.

В следующем фрагменте программы делается попытка открыть файл. Если это не получается, выводится сообщение об ошибке и программа завершает свою работу. Обратите внимание на то, что в случае успеха операции функция open() возвращает дескриптор открытого файла, иначе — -1.

fd = open("inputfile.txt", O_RDONLY);

if (fd == -1) {

 /* Открыть файл не удалось.

    Вывод сообщения об ошибке и выход. */

 fprintf(stderr, "error opening file: %s\n", strerror(errno));

 exit(1);

}

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

Одни из кодов, с которым приходится сталкиваться наиболее часто, особенно в функциях ввода-вывода, — это EINTR. Ряд функций, в частности read(), select() и sleep(), требует определенного времени на выполнение. Они называются блокирующими, так как выполнение программы приостанавливается до тех пор, пока функция не завершится. Но если программа, будучи заблокированной, принимает сигнал, функция завершается, не закончив выполнение операции. В данном случае в переменную errno записывается значение EINTR. Обычно в подобной ситуации следует повторно выполнить системный вызов.

Ниже приведен фрагмент программы, в котором функция chown() меняет владельца файла, определяемого переменной path, назначая вместо него пользователя с идентификатором user_id. Если функция завершается неуспешно, дальнейшие действия программы зависят от значения переменной errno. Обратите внимание на интересный момент: при обнаружении возможной ошибки в самой программе ее выполнение завершается с помощью функции abort() или assert(), вследствие чего генерируется файл дампа оперативной памяти. Анализ этого файла может помочь выяснить природу таких ошибок. В случае невосстанавливаемых ошибок, например нехватки памяти, программа завершается с помощью функции exit(), указывая ненулевой код ошибки: в подобных ситуациях файл дампа оказывается бесполезным.

rval = chown(path, user_id, -1);

if (rval != 0) {

 /* Сохраняем переменную errno, поскольку она будет изменена

    при следующем системном вызове. */

 int error_code = errno;

 /* Операция прошла неуспешно; в случае ошибки функция chown()

    должна вернуть значение -1. */

 assert(rval == -1);

 /* Проверяем значение переменной errno и выполняем

    соответствующее действие. */

 switch (error_code) {

 case EPERM: /* Доступ запрещен. */

 case EROFS: /* Переменная PATH ссылается на файловую

                систему, доступную только для чтения. */

 case ENAMETOOLONG: /* Переменная PATH оказалась слишком длинной. */

 case ENOENT: /* Переменная PATH ссылается на

                 несуществующий файл. */

 case ENOTDIR: /* Один из компонентов переменной PATH

                  не является каталогом. */

 case EACCES: /* Один из компонентов переменной PATH

                 недоступен. */

  /* Что-то неправильно с файлом, выводим сообщение

     об ошибке. */

  fprintf(stderr, "error changing ownership of %s: %s\n",

   path, strerror(error_code));

  /* He завершаем программу; можно предоставить пользователю

     шанс открыть другой файл. */

  break;

 case ЕFAULT:

  /* Переменная PATH содержит неправильный адрес. Это, скорее

     всего, ошибка программы. */

  abort();

 case ENOMEM:

  /* Ядро столкнулось с нехваткой памяти. */

  fprintf(stderr, "%s\n", strerror(error_code));

  exit(1);

 default:

  /* Произошла какая-то другая, непредвиденная ошибка. Мы

     пытались обработать все возможные коды ошибок. Если

     что-то пропущено, то это ошибка программы! */

  abort();

 };

}

В самом начале программного фрагмента можно было поставить следующий код:

rval = chown(path, user_id, -1);

assert(rval == 0);

Но в таком случае, если функция завершится неуспешно, у нас не будет возможности обработать или исправить ошибку и даже просто сообщить о ней. Какую форму проверки использовать — зависит от требований к обнаружению и последующему исправлению ошибок в программе.

 

2.2.4. Ошибки выделения ресурсов

Обычно при неудачном выполнении системного вызова наиболее приемлемое решение — отменить текущую операцию, но не завершить программу, так как можно восстановить ее нормальную работу. Один из способов сделать это — выйти из текущей функции, передав через оператор return код ошибки вызывающему модулю.

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

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

1. выделяет буфер;

2. открывает файл;

3. читает содержимое файла и записывает его в буфер;

4. закрывает файл;

5. возвращает буфер вызывающему модулю.

Если файл не существует, этап 2 закончится неудачей. Подходящая реакция в этом случае — вернуть из функции значение NULL. Но если буфер уже был выделен на этапе 1, существует опасность потери этого ресурса. Нужно не забыть освободить буфер где-то в программе. Если же неудачей завершится этап 3, требуется не только освободить буфер перед выходом из функции, но и закрыть файл.

В листинге 2.6 показан пример реализации такой функции.

Листинг 2.6. ( readfile.c ) Освобождение ресурсов при возникновении аварийных ситуаций

#include

#include

#include

#include

#include

char* read_from_file(const char* filename, size_t length) {

 char* buffer;

 int fd;

 ssize_t bytes_read;

 /* Выделяем буфер. */

 buffer = (char*)malloc(length);

 if (buffer == NULL)

  return NULL;

 /* Открываем файл. */

 fd = open(filename, O_RDONLY);

 if (fd == 1) {

  /* Открыть файл не удалось. Освобождаем буфер

     перед выходом. */

  free(buffer);

  return NULL;

 }

 /* Чтение данных. */

 bytes_read = read(fd, buffer, length);

 if (bytes_read != length) {

  /* Чтение не удалось. Освобождаем буфер и закрываем файл

     перед выходом. */

  free(buffer);

  close(fd);

  return NULL;

 }

 /* Все прошло успешно. Закрываем файл и возвращаем буфер

    в программу. */

 close(fd);

 return buffer;

}

При завершении программы операционная система Linux освобождает выделенную память, ссылки на открытые файлы и большинство других ресурсов, поэтому перед вызовом функции exit() нет необходимости удалять буферы и закрывать файлы. Но некоторые другие совместно используемые ресурсы приходится все же освобождать вручную. В частности, это относится к временным файлам и совместным буферам памяти: они способны "пережить" программу.

 

2.3. Создание и использование библиотек

 

Практически со всеми программами компонуется одна или несколько библиотек. К любой программе, использующей функции языка С (например, printf() или malloc()), подключается библиотека времени выполнения. Если у программы есть графический интерфейс, вместе с ней компонуются библиотеки функций работы с окнами. Когда программа обращается к СУБД, она делает это посредством функции библиотеки, предоставленной разработчиком данной СУБД.

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

 

2.3.1. Архивы

Архив (или статическая библиотека) — это коллекция объектных файлов, хранящаяся в виде одного файла (он является примерным эквивалентом LIB-файла в Windows). Когда архив поступает на вход компоновщика, тот ищет в нем нужные объектные файлы, извлекает их и подключает к программе так, как если бы они были указаны непосредственно.

Архив создается посредством команды ar. Архивные файлы традиционно имеют расширение .a, а не .o, которое закреплено за отдельными объектными файлами. Вот как объединить файлы test1.o и test2.o в единый архив libtest.a:

% ar cr libtest.a test1.o test2.o

Флаги cr сообщают команде ar о необходимости создать архив. Теперь можно подключать этот архив к программам с помощью флага -ltest компилятора gcc или g++, как описывалось в разделе 1.2.2, "Компоновка объектных файлов".

Обнаруживая в командной строке архив, компоновщик ищет в нем определения всех символических констант (функций или переменных), на которые дается ссылка в уже обработанных объектных файлах. Объектные файлы, содержащие определения этих констант, извлекаются из архива и включаются в исполняемый файл. В связи с тем что компоновщик просматривает архив один раз, архивные файлы нужно указывать в конце командной строки. Предположим, например, что имеются два файла: test.c (листинг 2.7) и app.c (листинг 2.8).

Листинг 2.7. ( test.c ) Первый исходный файл

int f() {

 return 3;

}

Листинг 2.8. ( app.c ) Второй исходный файл

int main() {

 return f();

}

Теперь допустим, что файл test.o включен вместе с другими объектными файлами в архив libtest.a. Тогда следующая команда не будет работать:

% gcc -о app -L. -ltest app.о

app.о: In function 'main':

app.о(.text+0x4): undefined reference to 'f'

collect2: ld returned 1 exit status

Как следует из сообщения об ошибке, несмотря на то что файл libtest.а содержит определение функции f(), компоновщик не нашел ее. Это объясняется тем. что компоновщик анализирует свои аргументы последовательно, слева направо, просматривая архив сразу же, как только он встречается в командной строке. На тот момент компоновщик еще не знал, что в дальнейшем ему встретится ссылка на функцию f(). Если сделать небольшую перестановку, все заработает:

% gcc -о app арр.о -L. -ltest

Теперь наличие в файле app.о ссылки на функцию f() заставляет компоновщик включить в программу объектный файл test.o из архива libtest.а.

 

2.3.2. Совместно используемые библиотеки

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

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

Чтобы создать совместно используемую библиотеку, нужно сначала скомпилировать составляющие ее объектные файлы с указанием опции -fPIC, например:

% gcc -с -fPIC test1.c

Опция -fPIC сообщает компилятору о том, что файл test1.o станет частью совместно используемой библиотеки.

Позиционно-независимый код

Аббревиатура PIC (Position-Independent Code) в названии опции расшифровывается как "позиционно-независимый код". Функции в совместно используемой библиотеке могут загружаться по разным адресам разными программами, поэтому код библиотеки не должен зависеть от адреса (или позиции), по которому она загружена. Все это никак не касается программистов, просто нужно не забывать указывать флаг -fPIC при компиляции файлов, которые могут включаться в совместно используемую библиотеку.

Затем следует объединить объектные файлы в библиотеку:

% gcc -shared -fPIC -о libtest.so test1.o test2.o

Опция -shared заставляет компоновщик создать совместно используемую библиотеку, а не обычный исполняемый файл. Такие библиотеки имеют расширение .so. Подобно статическому архиву, имя библиотеки всегда начинается с префикса lib, указывающего на то. что файл является библиотекой.

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

% gcc -о app арр.о -L. ltest

Предположим, имеются оба файла: libtest.а и libtest.so. Каким образом компоновщик принимает решение? Он просматривает каждый заданный каталог (сначала те, что указаны в опции -L, затем стандартные) и, как только обнаруживает хотя бы один из файлов, тут же прекращает поиск. Если в найденном каталоге присутствует только один из файлов, он и выбирается. В противном случае выбор делается в пользу совместно используемой библиотеки, если явно не указано обратное. Отдать приоритет статическому архиву позволяет опция -static. Например, следующая команда подключит к программе архив libtest.a, даже если присутствует библиотека libtest.so:

% gcc -static -о app арр.о -L. -ltest

Команда ldd выводит список совместно используемых библиотек, подключенных к заданному исполняемому файлу. Все они должны быть доступны при запуске программы. Обратите внимание на то, что команда ldd сообщает о наличии дополнительной библиотеки: ld-linux.so. Она является частью механизма динамической компоновки в Linux.

Переменная LD_LIBRARY_PATH

Когда к программе подключается совместно используемая библиотека, компоновщик помещает в исполняемый файл ссылку на нее, но в этой ссылке указан не полный путь к библиотеке, а только имя файла. При запуске программы система сама находит библиотеку и загружает ее. По умолчанию система просматривает лишь каталоги /lib и /usr/lib. Если библиотека находится в другом каталоге, она не будет найдена и система откажется загружать программу.

Одно из решений заключается в компоновке программы с указанием флага -Wl,-rpath:

% gcc -о app арр.о -L. -ltest -Wl,-rpath,/usr/local/lib

Теперь в случае запуска программы app система будет искать требуемые библиотеки также в каталоге /usr/local/lib.

Но есть и другое решение: устанавливать переменную LD_LIBRARY_PATH при запуске программы. Подобно переменной среды PATH, переменная LD_LIBRARY_PATH представляет собой разделенный двоеточиями список каталогов. Если, к примеру, она равна /usr/local/lib:/opt/lib, то каталоги /usr/local/lib и /opt/lib будут просматриваться перед стандартными каталогами /lib и /usr/lib. Необходимо также учитывать, что при наличии данной переменной компоновщик будет просматривать заданные в ней каталоги, обнаруживая опцию -L в командной строке.

 

2.3.3. Стандартные библиотеки

Даже если при компоновке программы не были заданы библиотеки, все равно одна из них почти наверняка присутствует. Дело в том, что компилятор gcc автоматически подключает к программе стандартную библиотеку языка С: libc. В нее, однако, не входят математические функции. Они находятся в отдельной библиотеке, libm, которую нужно компоновать явно. Например, чтобы скомпилировать и скомпоновать программу compute, использующую тригонометрические функции (такие как sin() и cos()), необходимо задать следующую команду:

% gcc -о compute compute.c -lm

При компоновке программ, написанных на C++, компилятор c++ или g++ автоматически подключает к ним стандартную библиотек языка C++: libstdc++.

 

2.3.4. Зависимости между библиотеками

Библиотеки часто связаны одна с другой. Например, во многих Linux-системах есть библиотека libtiff, содержащая функции чтения и записи графических файлов формата TIFF. Она, в свою очередь, использует библиотеки libjpeg (подпрограммы обработки JPEG-изображений) и libz (подпрограммы сжатия).

В листинге 2.9 показана небольшая программа, использующая функции библиотеки libtiff для работы с TIFF-файлом.

Листинг 2.9. ( tifftest.c ) Применение библиотеки libtiff

#include

#include

int main(int argc, char** argv) {

 TIFF* tiff;

 tiff = TIFFOpen(argv[1], "r");

 TIFFClose(tiff);

 return 0;

}

При компиляции этого файла необходимо указать флаг -ltiff:

% gcc -о tifftest tifftest.c -ltiff

По умолчанию будет скомпонована совместно используемая версия библиотеки: /usr/lib/libtiff.so. В связи с тем что она обращается к библиотекам libjpeg и libz (одна совместно используемая библиотека может ссылаться на другие аналогичные библиотеки, от которых она зависит), будут также подключены их совместно используемые версии. Чтобы проверить это, воспользуемся командой ldd:

% ldd tifftest

 libtiff.so.3 => /usr/lib/libtiff.so.3 (0x4001d000)

 libc.so.6 => /lib/libc.so.6 (0x40060000)

 libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x40155000)

 libz.so.1 => /usr/lib/libz.so.1 (0x40174000)

 /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

В противоположность этому статические библиотеки не могут указывать на другие библиотеки. Если попытаться подключить к программе статическую версию библиотеки libtiff, указав в командной строке опцию -static, компоновщик столкнется с нераспознаваемыми символическими константами:

% gcc -static -о tifftest tifftest.с -ltiff

/usr/bin/../lib/libtiff.a(tif_jpeg.o): In function

                                       'TIFFjpeg_error_exit':

tif_jpeg.о(.text+0x2a): undefined reference to 'jpeg_abort'

/usr/bin/../lib/libtiff.a (tif_jpeg.o): In function

                                        'TIFFjpeg_create_compress':

tif_jpeg.o(.text+0x8d): undefined reference to 'jpeg_std_error'

tif_jpeg.o(.text+0xcf): undefined reference to

                        'jpeg_CreateCompress'

...

В случае статической компоновки программы нужно самостоятельно указать две другие библиотеки:

% gcc -static -o tifftest tifftest.c -ltiff -ljpeg -lz

Иногда между двумя библиотеками образуется взаимная зависимость. Другими словами, первый архив ссылается на символические константы, определенные во втором архиве, и наоборот. Такая ситуация, как правило, является следствием неправильного проектирования. В этом случае нужно указать в командной строке одну и ту же библиотеку несколько раз. Компоновщик просмотрит библиотеку столько раз, сколько она присутствует в командной строке. Рассмотрим пример:

% gcc -o app арр.о -lfoo -lbar -lfoo

Теперь, даже если библиотека libfoo.a ссылается на символические константы в библиотеке libbar.a и наоборот, программа будет успешно скомпонована.

 

2.3.5. Преимущества и недостатки библиотек

Познакомившись со статическими архивами и совместно используемыми библиотеками. читатели, очевидно, задумались: какие же из них лучше использовать? Есть несколько важных моментов, о которых следует помнить.

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

С этим связано еще одно преимущество совместно используемых библиотек: пользователи могут обновлять библиотеки, не затрагивая связанные с ними программы. Предположим, к примеру, что была создана библиотека, содержащая функции управления HTTP- соединениями. Потенциально с ней может работать множество программ. Если впоследствии в библиотеке обнаружится ошибка, достаточно будет просто заменить ее файл, и все программы, использующие данную библиотеку, немедленно обновятся. Не придется выполнять перекомпоновку всех программ, как в случае статического архива.

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

Если библиотеки не должны инсталлироваться в каталог /lib или /usr/lib, нужно дважды подумать, стоит ли их делать совместно используемыми. (Библиотеки нельзя помещать в указанные каталоги, если предполагается, что программу будут инсталлировать пользователи, не имеющие привилегий системного администратора.) В частности, прием с флагом -Wl,-rpath не будет работать, поскольку не известно, где именно окажутся библиотеки. А просить пользователей устанавливать переменную LD_LIBRARY_PATH — не выход из положения, так как это означает для них выполнение дополнительного (для некоторых — не самого тривиального) действия.

Оценивать преимущества и недостатки двух типов библиотек нужно для каждой создаваемой программы отдельно.

 

2.3.6. Динамическая загрузка и выгрузка

Иногда на этапе выполнения программы требуется загрузить некоторый код без явной компоновки. Рассмотрим приложение, поддерживающее подключаемые модули: Web-броузер. Архитектура броузера позволяет сторонним разработчикам создавать дополнительные модули, расширяющие функциональные возможности броузера. Модуль реализуется в виде совместно используемой библиотеки и размещается в заранее известном каталоге. Броузер автоматически загружает код из этого каталога.

Для этих целей в Linux существует специальная функция dlopen(). Например, открыть библиотеку libtest.so можно следующим образом:

dlopen("libtest.so", RTLD_LAZY)

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

Объявление функций работы с динамическими библиотеками находится в файле . Использующие их программы должны компоноваться с флагом -ldl, обеспечивающим подключение библиотеки libdl.

Функция dlopen() возвращает значение типа void*, используемое в качестве дескриптора динамической библиотеки. Это значение можно передавать функции dlsym(), которая возвращает адрес функции, загружаемой из библиотеки. Например, если в библиотеке libtest.so определена функция my_function(), то она вызывается следующим образом:

void* handle = dlopen("libtest.so", RTLD_LAZY);

void (*test)() = dlsym(handle, "my_function");

(*test)();

dlclose(handle);

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

Обе функции, dlopen() и dlsym(), в случае неудачного завершения возвращают NULL. В данной ситуации можно вызвать функцию dlerror() (без параметров), чтобы получить текстовое описание возникшей ошибки.

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

Когда совместно используемая библиотека пишется на C++, имеет смысл объявлять общедоступные функции со спецификатором extern "С". Например, если функция my_function() написана на C++ и находится в совместно используемой библиотеке, а нужно обеспечить доступ к ней с помощью функции dlsym(), объявите ее следующим образом:

extern "С" void my_function();

Тем самым компилятору C++ будет запрещено подменять имя функции. При отсутствии спецификатора extern "С" компилятор подставит вместо имени my_function совершенно другое имя, в котором закодирована информация о данной функции. Компилятор языка С не заменяет имена; он работает с теми именами, которые назначены пользователем.

 

Глава 3

Процессы

 

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

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

Большинство описанных в данной главе функций управления процессами доступно и в других UNIX-системах. В основном они объявлены в файле , но не помешает проверить это в документации.

 

3.1. Знакомство с процессами

 

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

 

3.1.1. Идентификаторы процессов

Каждый процесс в Linux помечается уникальным идентификатором (PID, process identifier). Идентификаторы — это 16-разрядные числа, назначаемые последовательно по мере создания процессов.

У всякого процесса имеется также родительский процесс (за исключением специального демона init, о котором рассказывается в разделе 3.4.3, "Процессы-зомби"). Таким образом, все процессы Linux организованы в виде древовидной иерархии, на вершине которой находится процесс init. К атрибутам процесса относится идентификатор его предка (PPID, parent process identifier).

Работая с идентификаторами процессов в программах, написанных на языках С и C++, следует объявлять соответствующие переменные как имеющие тип pid_t (определен в файле ). Программа может узнать идентификатор своего собственного процесса с помощью системного вызова getpid(), а идентификатор своего родительского процесса — с помощью вызова getppid(). В листинге 3.1 показано, как это сделать.

Листинг 3.1. ( print-pid.c ) Вывод идентификатора процесса

#include

#include

int main() {

 printf("The process ID is %d\n", (int)getpid());

 printf("The parent process ID is %d\n", (int)getppid());

 return 0;

}

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

 

3.1.2. Получение списка активных процессов

Команда ps отображает список процессов, работающих в данный момент в системе. Версия этой команды в GNU/Linux имеет множество опций, так как пытается быть совместимой со своими "родственниками" в других UNIX-системах. С помощью опций можно указывать, о каких процессах и какую именно требуется получить информацию.

Будучи вызванной без аргументов, команда ps выводит список тех процессов, управляющим терминалом которых является ее собственный терминал:

% ps

  PID TTY       TIME CMD

21693 pts/8 00:00:00 bash

21694 pts/8 00:00:00 ps

В данном случае мы видим два процесса. Первый из них. bash, — это интерпретатор команд, запущенный на данном терминале. Второй — выполняющийся экземпляр самой команды ps. В самом левом столбце, PID, отображаются идентификаторы процессов.

Более полный список можно получить с помощью следующей команды:

% ps -е -о pid,ppid,command

Опция -е заставляет команду ps отображать все процессы, выполняющиеся в системе. Опция -о pid,ppid,command сообщает о том, какая информация о процессе нас интересует. В данном случае это идентификатор самого процесса, идентификатор его родительского процесса и команда, посредством которой был запущен процесс.

Форматы вывода команды ps

В опции -o через запятую указываются столбцы которые должны быть включены в вывод команды ps . Например, команда ps -о pid,user,start_time,command отображает идентификатор процесса, имя его владельца, время запуска а также команду, соответствующую процессу. Полный список опций и столбцов можно узнать на man -странице команды ps . Имеются три предопределенных формата вывода: -f (полный листинг), -l (длинный листинг) и -j (вывод заданий)

Ниже приведено несколько первых и последних строк, выдаваемых этой командой в нашей системе:

% ps -e -о pid,ppid,command

PID PPID COMMAND

  1    0 init [5]

  2    1 [kflushd]

  3    1 [kupdate]

...

21725 21693 xterm

21727 21725 bash

21728 21727 ps -e -o pid,ppid,command

Заметьте: родительский идентификатор команды ps, 21727, соответствует интерпретатору bash, из которого была вызвана команда. В свою очередь, родительский идентификатор интерпретатора, 21725, принадлежит программе xterm — эмулятору терминала, в котором выполняется интерпретатор.

 

3.1.3. Уничтожение процесса

Для уничтожения процесса предназначена команда kill. Ей достаточно указать идентификатор требуемого процесса.

Команда kill посылает процессу сигнал SIGTERM, являющийся запросом на завершение. По умолчанию, если в программе отсутствует обработчик данного сигнала, процесс просто завершает свою работу. О сигналах речь пойдет в разделе 3.3, "Сигналы".

 

3.2. Создание процессов

 

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

 

3.2.1. Функция system()

Функция system() определена в стандартной библиотеке языка С и позволяет вызывать из программы системную команду, как если бы она была набрана в командной строке. По сути, эта функция запускает стандартный интерпретатор Bourne shell (/bin/sh) и передает ему команду на выполнение. Например, программа, представленная в листинге 3.2, вызывает команду ls -l /, отображающую содержимое корневого каталога.

Листинг 3.2. ( system.c ) Использование функции system()

#include

int main() {

 int return_value;

 return_value = system("ls -l /");

 return return_value;

}

Функция system() возвращает код завершения указанной команды. Если интерпретатор не может быть запущен, возвращается значение 127, а в случае возникновения других ошибок — -1.

Поскольку функция system() запускает интерпретатор команд, она подвержена всем тем ограничениям безопасности, что и системный интерпретатор. Рассчитывать на наличие какой-то конкретной версии Bourne shell не приходится. В большинстве UNIX-систем программа /bin/sh представляет собой символическую ссылку на другой интерпретатор. В Linux — это bash (Bourne-Again SHell), причем в разных дистрибутивах присутствуют разные его версии. Вызов из функции system() программы с привилегиями пользователя root также может иметь неодинаковые последствия в разных системах. Таким образом, лучше создавать процессы с помощью функций fork() и exec().

 

3.2.2. Функции fork() и exec()

В DOS и Windows API имеется семейство функций spawn(). Они принимают в качестве аргумента имя программы, создают новый экземпляр ее процесса и запускают его. В Linux нет функции, которая делала бы все это за один заход. Вместо этого имеется функция fork(), создающая дочерний процесс, который является точной копией родительского процесса, и семейство функций exec(), заставляющих требуемый процесс перестать быть экземпляром одной программы и превратиться в экземпляр другой программы. Чтобы создать новый процесс, нужно сначала с помощью функции fork() создать копню текущего процесса, а затем с помощью функции exec() преобразовать одну из копий в экземпляр запускаемой программы.

Вызов функции fork()

Вызывая функцию fork(), программа создает свой дубликат, называемый дочерним процессом. Родительский процесс продолжает выполнять программу с той точки, где была вызвана функция fork(). То же самое делает и дочерний процесс.

Как же различить между собой оба процесса? Во-первых, дочерний процесс — это новый, только что появившийся в системе процесс, поэтому его идентификатор отличается от идентификатора родительского процесса. Таким образом, программа может вызвать функцию getpid() и узнать, где именно она находится. Но сама функция fork() реализует другой способ: она возвращает разные значения в родительском и дочернем процессах. Родительский процесс получает идентификатор своего потомка, а дочернему процессу возвращается 0. В системе нет процессов с нулевым идентификатором, так что программа легко разбирается в ситуации.

В листинге 3.3 приведен пример ветвления программы с помощью функции fork(). Учтите, что первая часть инструкции if выполняется только в родительском процессе, тогда как ветвь else — только в дочернем.

Листинг 3.3. ( fork.c ) Ветвление программы с помощью функции fork()

#include

#include

#include

int main() {

 pid_t child_pid;

 printf("The main program process ID is %d\n",

  (int)getpid());

 child_pid = fork();

 if (child_pid != 0) {

  printf("This is the parent process, with ID %d\n",

   (int)getpid());

  printf("The child's process ID is %d\n", (int)child_pid);

 } else

  printf("This is the child process, with ID %d\n",

   (int)getpid());

 return 0;

}

Семейство функций exec()

Функции семейства exec() заменяют программу, выполняющуюся в текущем процессе, другой программой. Когда программа вызывает функцию exec(), ее выполнение немедленно прекращается и начинает работу новая программа.

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

■ Функции, в названии которых присутствует суффикс 'p' (execvp() и execlp()), принимают в качестве аргумента имя программы и ищут эту программу в каталогах, определяемых переменном среды PATH. Всем остальным функциям нужно передавать полное путевое имя программы.

■ Функции, в названии которых присутствует суффикс 'v' (execv(), execvp() и execve()), принимают список аргументов программы в виде массива строковых указателей, оканчивающегося NULL-указателем. Функции с суффиксом 'l' (execl(), execlp() и execle()) принимают список аргументов переменного размера.

■ Функции, в названии которых присутствует суффикс 'e' (execve() и execle()), в качестве дополнительного аргумента принимают массив переменных среды. Этот массив содержит строковые указатели и оканчивается пустым указателем. Каждая строка должна иметь вид " ПЕРЕМЕННАЯ = значение " .

Поскольку функция exec() заменяет одну программу другой, она никогда не возвращает значение — только если вызов программы оказался невозможен в случае ошибки.

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

Совместное использование функций fork() и exec()

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

Программа, показанная в листинге 3.4, отображает содержимое корневого каталога с помощью команды ls, как и программа в листинге 3.2. Но на этот раз команда ls вызывается не из интерпретатора, а напрямую; ей передаются аргументы -l и /.

Листинг 3.4. ( fork-exec.с ) Совместное использование функций fork() и exec()

#include

#include

#include

#include

/* Запуск дочернего процесса в виде новой программы. Параметр

   PROGRAM — это имя вызываемой программы; ее поиск будет

   осуществляться в каталогах, определяемых переменной среды PATH.

   Параметр ARG_LIST -- это список строковых аргументов,

   передаваемых программе (должен оканчиваться указателем NULL).

   Функция возвращает идентификатор порожденного процесса. */

int spawn(char* program, char** arg_list) {

 pid_t child_pid;

 /* Создание копии текущего процесса. */

 child_pid = fork();

 if (child_pid != 0)

  /* Это родительский процесс. */

  return child_pid;

 else {

  /* Выполнение указанной программы. */

  execvp(program, arg_list);

  /* Функция execvp() возвращает значение только в случае

    ошибки. */

  fprintf(stderr, "an error occurred in execvp\n");

  abort();

 }

}

int main() {

 /* Список аргументов, передаваемых команде ls. */

 char* arg_list[] = {

  "ls", /* argv[0] -- имя программы. */

  "-l",

  NULL /* Список аргументов должен оканчиваться указателем

          NULL. */

 };

 /* Порождаем дочерний процесс, который выполняет команду ls.

    Игнорируем возвращаемый идентификатор дочернего процесса. */

 spawn("ls", arg_list);

 printf("done with main program\n");

 return 0;

}

 

3.2.3. Планирование процессов

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

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

Для запуска программы с ненулевым фактором уступчивости необходимо воспользоваться командой nice -n. Рассмотрим следующий пример:

% nice -n 10 sort input.txt > output.txt

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

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

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

 

3.3. Сигналы

Сигналы — это механизм связи между процессами в Linux. Данная тема очень обширна, поэтому здесь мы рассмотрим лишь наиболее важные сигналы и методики управления процессами.

Сигнал представляет собой специальное сообщение, посылаемое процессу. Сигналы являются асинхронными: когда процесс принимает сигнал, он немедленно обрабатывает его, прерывая выполнение текущей функции и даже текущей строки программы. Есть несколько десятков различных сигналов, каждый из которых имеет свое функциональное назначение. Все они распознаются по номерам, но в программах для ссылки на сигналы пользуются символическими константами. В Linux эти константы определены в файле /usr/include/bits/signum.h (его не нужно включать в программы, для этого есть файл ).

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

Операционная система Linux посылает процессам сигналы в случае возникновения определенных ситуаций. Например, сигналы SIGBUS (ошибка на шине), SIGSEGV (нарушение сегментации) и SIGFPE (ошибка операции с плавающей запятой) могут быть посланы процессу, пытающемуся выполнить неправильную операцию. По умолчанию эти сигналы приводят к завершению процесса и созданию дампа оперативной памяти.

Процесс может сам послать сигнал другому процессу. Чаще всего возникает необходимость завершить требуемый процесс с помощью сигнала SIGTERM или SIGKILL. С помощью сигналов можно также передавать команды выполняющимся программам. Для этого существуют "пользовательские" сигналы SIGUSR1 и SIGUSR2. Иногда в аналогичных целях применяется сигнал SIGHUP, с помощью которого можно заставить программу повторно прочитать свои файлы конфигурации.

Функция sigaction() определяет правила обработки указанного сигнала. Первый ее аргумент — это номер сигнала. Следующие два аргумента представляют собой указатели на структуру sigaction; первый из них регистрирует новый обработчик сигнала, а второй содержит описание предыдущего обработчика. Наиболее важным полем структуры sigaction является sa_handler. Оно может содержать одно из трех значений:

■ SIG_DFL — выбор стандартного обработчика сигнала;

■ SIG_IGN — игнорирование сигнала,

■ указатель на функцию обработки сигнала; эта функция должна принимать один параметр (номер сигнала) и возвращать значение типа void.

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

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

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

Даже присвоение значения глобальной переменной несет потенциальную опасность, так как данная операция может занять два или три такта процессора, а за это время успеет прийти следующий сигнал, вследствие чего переменная окажется поврежденной. Если обработчик использует какую-то переменную в качестве флага поступления сигнала, она должна иметь специальный тип sig_atomic_t. Linux гарантирует, что операция присваивания значения такой переменной займет ровно один такт и не будет прервана. На самом деле тип sig_atomic_t в Linux эквивалентен типу int; более того, операции присваивания целочисленных переменных (32- и 16-разрядных) и указателей всегда атомарны. Использовать тип sig_atomic_t необходимо для того, чтобы программу можно было перенести в любую стандартную UNIX-систему.

В листинге 3.5 представлен шаблон программы, в которой функция-обработчик подсчитывает, сколько раз программа получает сигнал SIGUSR1.

Листинг 3.5. ( sigusr1.c ) Корректное применение обработчика сигнала

#include

#include

#include

#include

#include

sig_atomic_t sigusr1_count = 0;

void handler(int signal_number) {

 ++sigusr1_count;

}

int main() {

 struct sigaction sa;

 memset(&sa, 0, sizeof(sa));

 sa.sa_handler = &handler;

 sigaction(SIGUSR1, &sa, NULL);

 /* далее идет основной текст. */

 /* ... */

 printf("SIGUSR1 was raised %d times\n", sigusr1_count);

 return 0;

}

 

3.4. Завершение процесса

 

Обычно процесс завершается одним из двух способов: либо выполняющаяся программа вызывает функцию exit(), либо функция main() заканчивается. У каждого процесса есть код завершения — число, возвращаемое родительскому процессу. Этот код передается в качестве аргумента функции exit() или возвращается функцией main().

Возможно также аварийное завершение процесса, в ответ на получение сигнала. Таковыми могут быть, например, упоминавшиеся выше сигналы SIGBUS, SIGSEGV и SIGFPE. Есть сигналы, явно запрашивающие прекращение работы процесса. В частности, сигнал SIGINT посылается, когда пользователь нажимает . Сигнал SIGTERM посылается процессу командной kill по умолчанию. Если программа вызывает функцию abort(), она посылает сама себе сигнал SIGABRT. Самый "могучий" из всех сигналов — SIGKILL: он приводит к безусловному уничтожению процесса и не может быть ни блокирован, ни обработан.

Любой сигнал можно послать с помощью команды kill, указав дополнительный флаг. Например, чтобы уничтожить процесс, послав ему сигнал SIGKILL, воспользуйтесь следующей командой:

% kill -KILL идентификатор_процесса

Для отправки сигнала из программы предназначена функция kill(). Ее первым аргументом является идентификатор процесса. Второй аргумент — номер сигнала (стандартному поведению команды kill соответствует сигнал SIGTERM). Например, если переменная child_pid содержит идентификатор дочернего процесса, то следующая функция, вызываемая из родительского процесса, вызывает завершение работы потомка:

kill(child_pid, SIGTERM);

Для использования функции kill() необходимо включить в программу файлы и .

По существующему соглашению код завершения указывает на то, успешно ли выполнилась программа. Нулевой код говорит о том, что все в порядке, ненулевой код свидетельствует об ошибке. В последнем случае конкретное значение кода может подсказать природу ошибки. Подобным образом функционируют все компоненты GNU/Linux. Например, на это рассчитывает интерпретатор команд, когда в командных сценариях вызовы программ объединяются с помощью операторов && (логическое умножение) и || (логическое сложение) Таким образом, функция main() должна явно возвращать 0 при отсутствии ошибок.

Помните о следующем ограничении: несмотря на то что тип параметра функции exit(), как и тип возвращаемого значения функции main(), равен int, операционная система Linux записывает код завершения лишь в младший из четырех байтов. Это означает, что значение кода должно находиться в диапазоне от 0 до 127. Коды, значение которых больше 128, интерпретируются особым образом: когда процесс уничтожается вследствие получения сигнала, его код завершения равен 128 плюс номер сигнала.

 

3.4.1. Ожидание завершения процесса

Читатели, запускавшие программу fork-exec (см. листинг 3.4), должно быть, обратили внимание на то, что вывод команды ls часто появляется после того, как основная программа уже завершила свою работу. Это связано с тем, что дочерний процесс, в котором выполняется команда ls, планируется независимо от родительского процесса. Linux — многозадачная операционная система, процессы в ней выполняются одновременно, поэтому нельзя заранее предсказать, кто — предок или потомок — завершится раньше.

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

 

3.4.2. Системные вызовы wait()

Самая простая функция в семействе называется wait(). Она блокирует вызывающий процесс до тех пор, пока один из его дочерних процессов не завершится (или не произойдет ошибка). Код состояния потомка возвращается через аргумент, являющийся указателем на целое число. В этом коде зашифрована различная информация о потомке. Например, макрос WEXITSTATUS() возвращает код завершения дочернего процесса. Макрос WIFEXITED() позволяет узнать, как именно завершился процесс: обычным образом (с помощью функции exit() или оператора return функции main()) либо аварийно вследствие получения сигнала. В последнем случае макрос WTERMSIG() извлекает из кода завершения номер сигнала.

Ниже приведена доработанная версия функции main() из файла fork-exec.c. На этот раз программа вызывает функцию wait(), чтобы дождаться завершения дочернего процесса, в котором выполняется команда ls.

int main() {

 int child_status;

 /* Список аргументов, передаваемых команде ls. */

 char* arg_list[] = {

  "ls", /* argv[0] — имя программы. */

  "-l",

  "/",

  NULL /* Список аргументов должен оканчиваться указателем

          NULL. */

 };

 /* Порождаем дочерний процесс, который выполняет команду ls.

    Игнорируем возвращаемый идентификатор дочернего процесса. */

 spawn("ls*, arg_list);

 /* Дожидаемся завершения дочернего процесса. */

 wait(&child_status);

 if (WTFEXITED(child_status));

 printf("the child process exited normally, with exit code %d\n",

  WEXITSTATUS(child_status));

 else

  printf("the child process exited abnormally\n");

 return 0;

}

Расскажем о других функциях семейства. Функция waitpid() позволяет дождаться завершения конкретного дочернего процесса, а не просто любого. Функция wait3() возвращает информацию о статистике использования центрального процессора завершившимся дочерним процессом. Функция wait4() позволяет задать дополнительную информацию о том, завершения каких процессов следует дождаться.

 

3.4.3. Процессы-зомби

Если дочерний процесс завершается в то время, когда родительский процесс заблокирован функцией wait(), он успешно удаляется и его код завершения передается предку через функцию wait(). Но что произойдет, если потомок завершился, а родительский процесс так и не вызвал функцию wait()? Дочерний процесс просто исчезнет? Нет, ведь в этом случае информация о его завершении (было ли оно аварийным или нет и каков код завершения) пропадет. Вместо этого дочерний процесс становится процессом-зомби.

Зомби — это процесс, который завершился, но не был удален. Удаление зомби возлагается на родительский процесс. Функция wait() тоже это делает, поэтому перед ее вызовом не нужно проверять, продолжает ли выполняться требуемый дочерний процесс. Предположим, к примеру, что программа создает дочерний процесс, выполняет нужные вычисления и затем вызывает функцию wait(). Если к тому времени дочерний процесс еще не завершился, функция wait() заблокирует программу. В противном случае процесс на некоторое время превратится в зомби. Тогда функция wait() извлечет код его завершения, система удалит процесс и функция немедленно завершится.

Что же всё-таки случится, если родительский процесс не удалит своих потомков? Они останутся в системе в виде зомби. Программа, показанная в листинге 3.6, порождает дочерний процесс, который немедленно завершается, тогда как родительский процесс берет минутную паузу, после чего тоже заканчивает работу, так и не позаботившись об удалении потомка.

Листинг 3.6. ( zombie.c ) Создание процесса-зомби

#include «stdlib.h>

#include

#include

int main() {

 pid_t child_pid;

 /* Создание дочернего процесса. */

 child_pid = fork();

 if (child_pid > 0) {

  /* Это родительский процесс — делаем минутную паузу. */

  sleep(60);

 } else {

  /* Это дочерний процесс — немедленно завершаем работу. */

  exit(0);

 }

 return 0;

}

Скомпилируйте этот файл и запустите программу. Пока программа работает, перейдите в другое окно и просмотрите список процессов с помощью следующей команды:

% ps -е -o pid,ppid,stat,cmd

Эта команда отображает идентификатор самого процесса и его предка, а также статус процесса и его командную строку. Обратите внимание на присутствие двух процессов с именем zombie. Один из них — предок, другой — потомок. У последнего идентификатор родительского процесса равен идентификатору основного процесса zombie, при этом потомок обозначен как (несуществующий), а его код состояния равен Z (т.е. zombie — зомби).

Итак, мы хотим узнать, что будет, когда программа zombie завершится, не вызвав функцию wait(). Останется ли процесс-зомби? Нет — выполните команду ps и убедитесь в этом: оба процесса zombie исчезли. Дело в том, что после завершения программы управление ее дочерними процессами принимает на себя специальный процесс — демон init, который всегда работает, имея идентификатор 1 (это первый процесс, запускаемый при загрузке Linux). Демон init автоматически удаляет все унаследованные им дочерние процессы-зомби.

 

3.4.4. Асинхронное удаление дочерних процессов

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

Один подход заключается в периодическом вызове функции wait3() или wait4(). Функция wait() в данной ситуации не подходит, так как в случае отсутствия завершившегося дочернего процесса она заблокирует основную программу. А вот упомянутые две функции принимают дополнительный флаг WNOHANG, переводящий их в неблокируемый режим, в котором функция либо удаляет дочерний процесс, если он есть, либо просто завершается. В первом случае возвращается идентификатор процесса, во втором — 0.

Более элегантный подход состоит в асинхронном уведомлении родительского процесса о завершении потомка. Существуют разные способы сделать это, но проще всего воспользоваться сигналом SIGCHLD, посылаемым как раз тогда, когда завершается дочерний процесс. По умолчанию программа никак не реагирует на этот сигнал, поэтому раньше вы могли и не знать о его существовании.

Таким образом, нужно организовать удаление дочерних процессов в обработчике сигнала SIGCHLD. Естественно, код состояния удаляемого процесса следует сохранять в глобальной переменной, если эта информация необходима основной программе. В листинге 3.7 показана программа, в которой реализована данная методика.

Листинг 3.7. ( sigchld.c ) Удаление дочерних процессов в обработчике сигнала SIGCHLD

#include

#include

#include

#include

sig_atomic_t child_exit_status;

void clean_up_child_process(int signal_number) {

 /* Удаление дочернего процесса. */

 int status;

 wait(&status);

 /* Сохраняем статус потомка в глобальной переменной. */

 child_exit_status = status;

}

int main() {

 /* Обрабатываем сигнал SIGCHLD, вызывая функцию

    clean_up_child_process(). */

 struct sigaction sigchld_action;

 memset(&sigchld_action, 0, sizeof(sigchld_action));

 sigchld_action.sa_handler = &clean_up_child_process;

 sigaction(SIGCHLD, &sigchld_action, NULL);

 /* Далее выполняются основные действия, включая порождение

    дочернего процесса. */

 /* ... */

 return 0;

}

 

Глава 4

Потоки

 

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

С концептуальной точки зрения поток существует внутри процесса, являясь более мелкой единицей управления программой. При вызове программы Linux создает для нее новый процесс, а в нем — единственный поток, последовательно выполняющий программный код. Этот поток может создавать дополнительные потоки. Все они находятся в одном процессе, выполняя ту же самую программу, но, возможно, в разных ее местах.

Мы уже знаем, как программа порождает дочерний процесс. Первоначально он находится в родительской программе, получая копии ее виртуальной памяти, дескрипторов файлов и т.п. Модификация содержимого памяти, закрытие файлов и другие подобные действия в дочернем процессе не влияют на работу родительского процесса и наоборот. С другой стороны, когда программа создает поток, ничего не копируется. Оба потока — старый и новый — имеют доступ к общему виртуальному пространству, общим дескрипторам файлов и другим системным ресурсам. Если, к примеру, один поток меняет значение переменной, это изменение отражается на другом потоке. Точно так же, когда один поток закрывает файл, второй поток теряет возможность работать с этим файлом. В связи с тем что процесс и все его потоки могут выполнять лишь одну программу одновременно, как только одни из потоков вызывает функцию семейства exec(), все остальные потоки завершаются (естественно, новая программа может создавать собственные потоки).

В Linux реализована библиотека API-функций работы с потоками, соответствующая стандарту POSIX (она называется Pthreads). Все функции и типы данных библиотеки объявлены в файле . Эти функции не входят в стандартную библиотеку языка С, поэтому при компоновке программы нужно указывать опцию -lpthread в командной строке.

 

4.1. Создание потока

 

Каждому потоку в процессе назначается собственный идентификатор. При ссылке на идентификаторы потоков в программах, написанных на языке С или C++, нужно использовать тип данных pthread_t.

После создания поток начинает выполнять потоковую функцию. Это самая обычная функция, которая содержит код потока. По завершении функции поток уничтожается. В Linux потоковые функции принимают единственный параметр типа void* и возвращают значение аналогичного типа. Этот параметр называется аргументом потока. Через него программы могут передавать данные потокам. Аналогичным образом через возвращаемое значение программы принимают данные от потоков.

Функция pthread_create() создает новый поток. Ей передаются следующие параметры.

■ Указатель на переменную типа pthread_t, в которой сохраняется идентификатор нового потока.

■ Указатель на объект атрибутов потока. Этот объект определяет взаимодействие потока с остальной частью программы. Если задать его равным NULL, поток будет создан со стандартными атрибутами. Подробнее данная тема обсуждается в разделе 4.1.5, "Атрибуты потоков".

■ Указатель на потоковую функцию. Функция имеет следующий тип:

void* (*)(void*)

■ Значение аргумента потока (тип void*). Данное значение без каких-либо изменений передается потоковой функции.

Функция pthread_create() немедленно завершается, и родительский поток переходит к выполнению инструкции, следующей после вызова функции. Тем временем новый поток начинает выполнять потоковую функцию. ОС Linux планирует работу обоих потоков асинхронно, поэтому программа не должна рассчитывать на какую-то согласованность между ними.

Программа, представленная в листинге 4.1, создает поток, который непрерывно записывает символы 'x' в стандартный поток ошибок. После вызова функции pthread_create() основной поток начинает делать то же самое, но вместо символов 'x' печатаются символы 'o'.

Листинг 4.1. ( thread-create.c ) Создание потока

#include

#include

/* Запись символов 'x' в поток stderr.

   Параметр не используется.

   Функция никогда не завершается. */

void* print_xs(void* unseed) {

 while (1)

  fputc('x', stderr);

 return NULL;

}

/* Основная программа. */

int main() {

 pthread_t thread_id;

 /* Создание потока. Новый поток выполняет

    функцию print_xs(). */

 pthread_create(&thread_id, NULL, &print_xs, NULL);

 /* Непрерывная запись символов 'o' в поток stderr. */

 while (1)

  fputc('o', stderr);

 return 0;

}

Компиляция и компоновка программы осуществляются следующим образом:

% cc -o thread-create thread-create.c -lpthread

Запустите программу, и вы увидите, что символы 'x' и 'o' чередуются самым непредсказуемым образом.

При нормальных обстоятельствах поток завершается одним из двух способов. Один из них — выход из потоковой функции. Возвращаемое ею значение считается значением, передаваемым из потока в программу. Второй способ— вызов специальной функции pthread_exit(). Это может быть сделано как в потоковой функции, так и в любой другой функции, явно или неявно вызываемой из нее. Аргумент функции pthread_exit() является значением, которое возвращается потоком.

 

4.1.1. Передача данных потоку

Потоковый аргумент — это удобное средство передачи данных потокам. Но поскольку его тип void*, данные содержатся не в самом аргументе. Он лишь должен указывать на какую-то структуру или массив. Лучше всего создать для каждой потоковой функции собственную структуру, в которой определялись бы "параметры", ожидаемые потоковой функцией.

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

Программа, приведенная в листинге 4.2, напоминает предыдущий пример. На этот раз создаются два потока: один отображает символы 'x', а другой — символы 'o'. Чтобы вывод на экран не длился бесконечно, потокам передается дополнительный аргумент, определяющий, сколько раз следует отобразить символ. Одна и та же функция char_print() эксплуатируется обоими потоками, но каждый из них конфигурируется независимо с помощью структуры char_print_parms.

Листинг 4.2. ( thread-create2.c ) Создание двух потоков

#include

#include

/* Параметры для функции char_print(). */

struct char_print_parms {

 /* Отображаемый символ. */

 char character;

 /* Сколько раз его нужно отобразить. */

 int count;

};

/* Запись указанного числа символов в поток stderr. Аргумент

   PARAMETERS является указателем на структуру char_print_parms. */

void* char_print(void* parameters) {

 /* Приведение указателя к нужному типу. */

 struct char_print_parms* p =

  (struct char_print_parms*)parameters;

 int i;

 for (i = 0; i < p->count; ++i)

  fputc(p->character, stderr);

 return NULL;

}

/* Основная программа. */

int main() {

 pthread_t thread1_id;

 pthread_t thread2_id;

 struct char_print_parms thread1_args;

 struct char_print_parms thread2_args;

 /* Создание нового потока, отображающего 30000

    символов 'x'. */

 thread1_args.character = 'x';

 thread1_args.count = 30000;

 pthread_create(&thread1_id, NULL, &char_print, &thread1_args);

 /* Создание нового потока, отображающего 20000

    символов 'o'. */

 thread2_args.character = 'o';

 thread2_args.count = 20000;

 pthread_create(&thread2_id, NULL, &char_print, &thread2_args);

 return 0;

}

Но постойте! Приведенная программа имеет серьезную ошибку. Основной поток (выполняющий функцию main()) создает структуры thread1_args и thread2_args в виде локальных переменных, а затем передает указатели на них дочерним потокам. Что мешает Linux распланировать работу потоков так, чтобы функция main() завершилась до того, как будут завершены другие два потока? Ничего! Но если это произойдет, структуры окажутся удаленными из памяти, хотя оба потока все еще ссылаются на них.

 

4.1.2. Ожидание завершения потоков

Одно из решений описанной выше проблемы заключается в том, чтобы заставить функцию main() дождаться завершения обоих потоков. Нужна лишь функция наподобие wait(), которая работает не с процессами, а с потоками. Такая функция называется pthread_join(). Она принимает два аргумента: идентификатор ожидаемого потока и указатель на переменную void*, в которую будет записано значение, возвращаемое потоком. Если последнее не важно, задайте в качестве второго аргумента NULL.

В листинге 4.3 приведена исправленная версия функции main() из предыдущего, неправильного примера. В данном случае функция main() не завершается, пока оба дочерних потока не выполнят свои задания и не перестанут ссылаться на переданные им структуры.

Листинг 4.3. Исправленная функция main() из файла thread-create.c

int main() {

 pthread_t thread1_id;

 pthread_t thread2_id;

 struct char_print_parms thread1_args;

 struct char_print_parms thread2_args;

 /* Создание нового потока, отображающего 30000

    символов 'x'. */

 thread1_args.character = 'x';

 thread1_args.count = 30000;

 pthread_create(&thread1_id, NULL, &char_print, &thread1_args);

 /* Создание нового потока, отображающего

    20000 символов 'o'. */

 thread2_args.character = 'o';

 thread2_args.count = 20000;

 pthread_create(&thread2_id, NULL, &char_print, &thread2_args);

 /* Убеждаемся, что завершился первый поток. */

 pthread_join(thread1_id, NULL);

 /* Убеждаемся, что завершился второй поток. */

 pthread_join(thread2_id, NULL);

 /* Теперь можно спокойно завершать работу. */

 return 0;

}

Мораль сей басни такова: убедитесь, что любые данные, переданные потоку по ссылке, не удаляются (даже другим потоком) до тех пор, пока поток не завершит свою работу с ними. Это относится как к локальным переменным, удаляемым автоматически при выходе за пределы своей области видимости, так и к динамическим переменным, удаляемым с помощью функции free() (или оператора delete в C++).

 

4.1.3. Значения, возвращаемые потоками

Если второй аргумент функции pthread_join() не равен NULL, то в него помещается значение, возвращаемое потоком. Как и потоковый аргумент, это значение имеет тип void*. Если поток возвращает обычное число типа int, его можно свободно привести к типу void*, а затем выполнить обратное преобразование по завершении функции pthread_join().

Программа, представленная в листинге 4.4, в отдельном потоке вычисляет n-е простое число и возвращает его в программу. Тем временем функция main() может продолжать свои собственные вычисления. Сразу признаемся: алгоритм последовательного деления, используемый в функции compute_prime(), весьма неэффективен. В книгах по численным методам описаны более мощные алгоритмы (например, "решето Эратосфена").

Листинг 4.4. ( primes.с ) Вычисление простых чисел в потоке

#include

#include

/* Находим простое число с порядковым номером N, где N -- это

   значение, на которое указывает параметр ARG. */

void* compute_prime(void* arg) {

 int candidate = 2;

 int n = *((int*)arg);

 while (1) {

  int factor;

  int is_prime = 1;

  /* Проверка простого числа путем последовательного деления. */

  for (factor = 2; factor < candidate; ++factor)

   if (candidate % factor == 0) {

    is_prime = 0;

    break;

   }

  /* Это то простое число, которое нам нужно? */

  if (is_prime) {

   if (--n == 0)

    /* Возвращаем найденное число в программу. */

    return (void*)candidate;

  }

  ++candidate;

 }

 return NULL;

}

int main() {

 pthread_t thread;

 int which_prime = 5000;

 int prime;

 /* Запускаем поток, вычисляющий 5000-е простое число. */

 pthread_create(&thread, NULL, &compute_prime, &which_prime);

 /* Выполняем другие действия. */

 /* Дожидаемся завершения потока и принимаем возвращаемое им

    значение. */

 pthread_join(thread, (void*)&prime);

 /* Отображаем вычисленный результат. */

 printf("The %dth prime number is %d.\n", which_prime, prime);

 return 0;

}

 

4.1.4. Подробнее об идентификаторах потоков

Иногда в программе возникает необходимость определить, какой поток выполняет ее в данный момент. Функция pthread_self() возвращает идентификатор потока, в котором она вызвана. Для сравнения двух разных идентификаторов предназначена функция pthread_equal().

Эти функции удобны для проверки соответствия заданного идентификатора текущему потоку. Например, поток не должен вызывать функцию pthread_join(), чтобы ждать самого себя (в подобной ситуации возвращается код ошибки EDEADLK). Избежать этой ошибки позволяет следующая проверка:

if (!pthread_equal(pthread_self(), other_thread)) pthread_join(other_thread, NULL);

 

4.1.5. Атрибуты потоков

Потоковые атрибуты — это механизм настройки поведения отдельных потоков. Вспомните, что функция pthread_create() принимает аргумент, являющийся указателем на объект атрибутов потока. Если этот указатель равен NULL, поток конфигурируется на основании стандартных атрибутов.

Для задания собственных атрибутов потока выполните следующие действия.

1. Создайте объект типа pthread_attr_t.

2. Вызовите функцию pthread_attr_init(), передав ей указатель на объект. Эта функция присваивает неинициализированным атрибутам стандартные значения.

3. Запишите в объект требуемые значения атрибутов.

4. Передайте указатель на объект в функцию pthread_create().

5. Вызовите функцию pthread_attr_destroy(), чтобы удалить объект из памяти. Сама переменная pthread_attr_t не удаляется; ее можно проинициализировать повторно с помощью функции pthread_attr_init().

Один и тот же объект может быть использован для запуска нескольких потоков. Нет необходимости хранить объект после того, как поток был создан.

Для большинства Linux-приложений интерес представляет один-единственный атрибут (остальные используются в приложениях реального времени): статус отсоединения потока. Поток может быть создан как ожидаемый (по умолчанию) или отсоединенный. Ожидаемый поток, подобно процессу, после своего завершения не удаляется автоматически операционной системой Linux. Код его завершения хранится где-то в системе (как у процесса-зомби), пока какой-нибудь другой поток не вызовет функцию pthread_join(), чтобы запросить это значение. Только тогда ресурсы потока считаются освобожденными. С другой стороны, отсоединенный поток, завершившись, сразу уничтожается. Другие потоки не могут вызвать по отношению к нему функцию pthread_join() или получить возвращаемое им значение.

Чтобы задать статус отсоединения потока, воспользуйтесь функцией pthread_attr_setdetachstate(). Первый ее аргумент — это указатель на объект атрибутов потока, второй — требуемый статус. Ожидаемые потоки создаются по умолчанию, поэтому в качестве второго аргумента имеет смысл указывать только значение PTHREAD_CREATE_DETACHED.

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

Листинг 4.5. ( detached.c ) Шаблон программы, создающей отсоединенный поток

#include

void* thread_function(void* thread_arg) {

 /* Тело потоковой функции... */

}

int main() {

 pthread_attr_t attr;

 pthread_t thread;

 pthread_attr_init(&attr);

 pthread_attr_setdetachstate(&attr, PTHREAD_CREATE_DETACHED);

 pthread_create(&thread, &attr, &thread_function, NULL);

 pthread_attr_destroy(&attr);

 /* Тело основной программы... */

 /* Дожидаться завершения второго потока нет необходимости. */

 return 0;

}

Даже если поток был создан ожидаемым, его позднее можно сделать отсоединенным. Для этого нужно вызвать функцию pthread_detach(). Обратное преобразование невозможно.

 

4.2. Отмена потока

 

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

Чтобы отменить поток, вызовите функцию pthread_cancel(), передав ей идентификатор требуемого потока. Далее можно дождаться завершения потока. Вообще-то, это обязательно нужно делать с целью освобождения ресурсов, если только поток не является отсоединенным. Отмененный поток возвращает специальное значение PTHREAD_CANCELED.

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

С точки зрения возможности отмены поток находится в одном из трех состояний.

■ Асинхронно отменяемый. Такой поток можно отменить в любой точке его выполнения.

■ Синхронно отменяемый. Поток можно отменить, но не везде. Запрос на отмену помещается в очередь, и поток отменяется только по достижении определенной точки.

■ Неотменяемый. Попытки отменить поток игнорируются. Первоначально поток является синхронно отменяемым.

 

4.2.1. Синхронные и асинхронные потоки

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

Чтобы сделать поток асинхронно отменяемым, воспользуйтесь функцией pthread_setcanceltype(). Эта функция влияет на тот поток, в котором она была вызвана. Первый ее аргумент должен быть PTHREAP_CANCEL_ASYNCHRONOUS в случае асинхронных потоков и PTHREAD_CANCEL_DEFERRED — в случае синхронных потоков. Второй аргумент — это указатель на переменную, в которую записывается предыдущее состояние потока.

Вот как можно сделать поток асинхронным:

pthread_setcanceltype(PTHREAD_CANCEL_ASYNCHRONOUS, NULL);

Что такое точка отмены и где она должна находиться? На этот вопрос нельзя дать прямой ответ. Точка отмены создается с помощью функции pthread_testcancel(). Все, что она делает, — это обрабатывает отложенный запрос на отмену в синхронном потоке. Ее следует периодически вызывать в потоковой функции в ходе длительных вычислений, там, где поток можно завершить без риска потери ресурсов или других побочных эффектов.

Некоторые функции неявно создают точки отмены. О них можно узнать на man-странице, посвященной функции pthread_cancel(). Учтите, что они могут вызываться в других функциях, которые, тем самым, косвенно станут точками отмены.

 

4.2.2. Неотменяемые потоки

Поток может вообще отказаться удаляться, вызвав функцию pthread_setcancelstate(). Как и в случае функции pthread_setcanceltype(), это оказывает влияние только на вызывающий поток. Первый аргумент функции должен быть PTHREAD_CANCEL_DISABLE, если нужно запретить отмену потока, и PTHREAD_CANCEL_ENABLE в противном случае. Второй аргумент — это указатель на переменную, в которую записывается предыдущее состояние потока.

Вот как можно запретить отмену потока:

pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, NULL);

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

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

В листинге 4.6 показан пример функции process_transaction(), осуществляющей данную задумку. Функция запрещает отмену потока до тех пор, пока баланс обоих счетов не будет изменен.

Листинг 4.6. ( critical_section.c ) Защита банковской транзакции с помощью критической секции

#include

#include

#include

/* Массив балансов счетов, упорядоченный по номеру счета. */

float* account_balances;

/* перевод денежной суммы, равной параметру DOLLARS, со счета

   FROM_ACCT на счет TO_ACCT. Возвращается 0, если транзакция

   завершена успешно, или 1, если баланс счета FROM_ACCT

   слишком мал. */

int process_transaction(int from_acct, int to_acct,

 float dollars) {

 int old_cancel_state;

 /* Проверяем баланс на счету FROM_ACCT. */

 if (account_balances(from_acct) < dollars)

  return 1;

 /* Начало критической секции. */

 pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, &old_cancel_state);

 /* переводим деньги. */

 account_balances[to_acct] += dollars;

 account_balances[from_acct] -= dollars;

 /* Конец критической секции. */

 pthread_setcancelstate(old_cancel_state, NULL);

 return 0;

}

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

 

4.2.3. Когда необходимо отменять поток

В общем случае не рекомендуется отменять поток, если его можно просто завершить. Лучше всего каким-то образом просигнализировать потоку о том, что он должен прекратить работу, а затем дождаться его завершения. Подробнее о способах взаимодействия с потоками речь пойдет ниже в этой главе.

 

4.3. Потоковые данные

 

В отличие от процессов, все потоки программы делят общее адресное пространство. Это означает, что если один поток модифицирует ячейку памяти (например, глобальную переменную), то это изменение отразится на всех остальных потоках. Таким образом, потоки могут работать с одними и теми же данными, не используя механизмы межзадачного взаимодействия (рассматриваются в главе 5, "Взаимодействие процессов").

Тем не менее у каждого потока — свой собственный стек вызова. Это позволяет всем потокам выполнять разный код, а также вызывать функции традиционным способом. При каждом вызове функции в любом потоке создается отдельный набор локальных переменных, которые сохраняются в стеке этого потока.

Иногда все же требуется продублировать определенную переменную, чтобы у каждого потока была ее собственная копия. С этой целью операционная система Linux предоставляет потокам область потоковых данных. Переменные, сохраняемые в этой области, дублируются для каждого потока, что позволяет потокам свободно работать с ними, не мешая друг другу. Доступ к потоковым данным нельзя получить с помощью ссылок на обычные переменные, ведь у потоков общее адресное пространство. В Linux имеются специальные функции для чтения и записи значений, хранящихся в области потоковых данных.

Можно создать сколько угодно потоковых переменных, при этом все они должны иметь тип void*. Ссылка на каждую переменную осуществляется по ключу. Для создания нового ключа, т.е. новой переменной, предназначена функция pthread_key_create(). Первым ее аргументом является указатель на переменную типа pthread_key_t. В нее будет записано значение ключа, посредством которого любой поток сможет обращаться к своей копии данных. Второй аргумент — это указатель на функцию очистки ключа. Она будет автоматически вызываться при уничтожении потока; ей передается значение ключа, соответствующее данному потоку. Это очень удобно, так как функция очистки вызывается даже в случае отмены потока в произвольной точке. Если потоковая переменная равна NULL, функция очистки не вызывается. Если же такая функция не нужна, задайте в качестве второго параметра функции pthread_key_create() значение NULL.

После того как ключ создан, каждый поток может назначать ему собственное значение, вызывая функцию pthread_setspecific(). Ее первый аргумент — это ключ, а второй — требуемое значение типа void*. Для чтения потоковых переменных предназначена функция pthread_getspecific(), единственным аргументом которой является ключ.

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

В листинге 4.7 показано, как осуществить задуманное. Для хранения файлового указателя в функции main() создается ключ, запоминаемый в переменной thread_log_key. Эта переменная является глобальной, поэтому она доступна всем потокам. Когда поток начинает выполнять свою потоковую функцию, он открывает журнальный файл и сохраняет указатель на него в своем ключе. Позднее любой поток может вызвать функцию write_to_thread_log(), чтобы записать сообщение в свой журнальный файл. Эта функция извлекает из области потоковых данных указатель на журнальный файл и помещает в файл требуемое сообщение.

Листинг 4.7. ( tsd.c ) Создание отдельного журнального файла для каждого потока с помощью области потоковых данных

#include

#include

#include

/* Ключ, связывающий указатель журнального файла с каждым

   потоком. */

static pthread_key_t thread_log_key;

/* Запись параметра MESSAGE в журнальный файл текущего потока. */

void write_to_thread_log(const char* message) {

 FILE* thread_log =

  (FILE*)pthread_getspecific(thread_log_key);

 fprintf(thread_log, "%s\n", message);

}

/* Закрытие журнального файла, на который указывает параметр

   THREAD_LOG. */

void close_thread_log(void* thread_log) {

 fclose((FILE*)thread_log);

}

void* thread_function(void* args) {

 char thread_log_filename[20];

 FILE* thread_log;

 /* Создание имени журнального файла для текущего потока. */

 sprintf(thread_log_filename, "thread%d.log",

  (int)pthread_self());

 /* Открытие журнального файла. */

 thread_log = fopen(thread_log_filename, "w");

 /* Сохранение указателя файла в области потоковых данных,

    под ключом thread_log_key. */

 pthread_setspecific(thread_log_key, thread_log);

 write_to_thread_log("Thread starting.");

 /* Далее идет основное тело потока... */

 return NULL;

}

int main() {

 int i;

 pthread_t threads[5];

 /* Создание ключа, который будет связывать указатели

    журнальных файлов с областью потоковых данных. Функция

    close_thread_log() закрывает все файлы. */

 pthread_key_create(&thread_log_key, close_thread_log);

 /* Создание потоков. */

 for (i = 0; i < 5; ++i)

  pthread_create(&(threads[i]), NULL, thread_function, NULL);

 /* Ожидание завершения всех потоков. */

 for (i = 0; i < 5; ++i)

  pthread_join(threads[i], NULL);

 return 0;

}

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

 

4.3.1. Обработчики очистки

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

Обработчик очистки вызывается при завершении потока. Он принимает один аргумент типа void*, который передается обработчику при его регистрации. Это позволяет использовать один и тот же обработчик для удаления нескольких экземпляров ресурса.

Обработчик очистки — это временная мера, требуемая только тогда, когда поток завершается или отменяется, не закончив выполнять определенный участок кода. При нормальных обстоятельствах ресурс должен удаляться явно.

Для регистрации обработчика следует вызвать функцию pthread_cleanup_push(), передав ей указатель на обработчик и значение его аргумента. Каждому такому вызову должен соответствовать вызов функции pthread_cleanup_pop(), которая отменяет регистрацию обработчика. Для удобства эта функция принимает дополнительный целочисленный флаг. Если он не равен нулю, при отмене регистрации выполняется операция очистки.

В листинге 4.8 показан фрагмент программы, в котором обработчик очистки применяется для удаления динамического буфера при завершении потока.

Листинг 4.8. ( cleanup.c ) Фрагмент программы, содержащий обработчик очистки потока

#include

#include

/* Выделение временного буфера. */

void* allocate_buffer(size_t size) {

 return malloc(size);

}

/* Удаление временного буфера. */

void deallocate_buffer(void* buffer) {

 free(buffer);

}

void do_some_work() {

 /* Выделение временного буфера. */

 void* temp_buffer = allocate_buffer(1024);

 /* Регистрация обработчика очистки для данного буфера. Этот

    обработчик будет удалять буфер при завершении или отмене

    потока. */

 pthread_cleanup_push(deallocate_buffer, temp_buffer);

 /* Выполнение других действий... */

 /* Отмена регистрации обработчика. Поскольку функции передается

    ненулевой аргумент, она выполняет очистку, вызывая функцию

    deallocate_buffer(). */

 pthread_cleanup_pop(1);

}

В данном случае функции pthread_cleanup_pop() передается ненулевой аргумент, поэтому функция очистки deallocate_buffer() вызывается автоматически. В данном простейшем случае можно было в качестве обработчика непосредственно использовать стандартную библиотечную функцию free().

 

4.3.2. Очистка потоковых данных в C++

Программисты, работающие на C++, привыкли к тому, что очистку за них делают деструкторы объектов. Когда объект выходит за пределы своей области видимости, либо по достижении конца блока, либо вследствие возникновения исключительной ситуации, среда выполнения C++ гарантирует вызов деструкторов для тех автоматических переменных, у которых они есть. Это удобный механизм очистки, работающий независимо от того, как осуществляется выход из конкретного программного блока.

Тем не менее, если поток вызывает функцию pthread_exit(), среда выполнения C++ не может гарантировать вызов деструкторов для всех автоматических переменных, находящихся в стеке потока. Чтобы этого добиться, нужно вызвать функцию pthread_exit() в рамках конструкции try/catch, охватывающей все тело потоковой функции. При этом перехватывается специальное исключение ThreadExitException.

Программа, приведенная в листинге 4.9, иллюстрирует данную методику. Потоковая функция сообщает о своем намерении завершить поток, генерируя исключение ThreadExitException, а не вызывая функцию pthread_exit() явно. Поскольку исключение перехватывается на самом верхнем уровне потоковой функции, все локальные переменные, находящиеся в стеке потока, будут удалены правильно.

Листинг 4.9. ( cxx-exit.cpp ) Безопасное завершение потока в C++

#include

class ThreadExitException {

public:

 /* Конструктор, принимающий аргумент RETURN_VALUE, в котором

    содержится возвращаемое потоком значение. */

 ThreadExitException(void* return_value) :

  thread_return_value_(return_value) {

 }

 /* Реальное завершение потока. В программу возвращается

    значение, переданное конструктору. */

 void* DoThreadExit() {

  pthread_exit(thread_return_value_);

 }

private:

 /* Значение, возвращаемое в программу при завершении потока. */

 void* thread_return_value_;

};

void do_some_work() {

 while (1) {

  /* Здесь выполняются основные действия... */

  if (should_exit_thread_immediately())

   throw ThreadExitException(/* поток возвращает */NULL);

 }

}

void* thread_function(void*) {

 try {

  do_some_work();

 } catch (ThreadExitException ex) {

  /* Возникла необходимость завершить поток. */

  ex.DoThreadExit();

 }

 return NULL;

}

 

4.4. Синхронизация потоков и критические секции

 

Программирование потоков — нетривиальная задача, ведь большинство потоков выполняется одновременно. К примеру, невозможно определить, когда система предоставит доступ к процессору одному потоку, а когда — другому. Длительность этого доступа может быть как достаточно большой, так и очень короткой, в зависимости от того, как часто система переключает задания. Если в системе есть несколько процессоров, потоки могут выполняться одновременно в буквальном смысле.

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

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

 

4.4.1. Состояние гонки

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

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

Листинг 4.10. ( job-queue1.c ) Потоковая функция, работающая с очередью заданий

#include

struct job {

 /* Ссылка на следующий элемент связанного списка. */

 struct job* next;

 /* Другие поля, описывающие требуемую операцию... */

};

/* Список отложенных заданий. */

struct job* job_queue;

/* Обработка заданий до тех пор, пока очередь не опустеет. */

void* thread_function(void* arg) {

 while (job_queue != NULL) {

  /* Запрашиваем следующее задание. */

  struct job* next_job = job_queue;

  /* Удаляем задание из списка. */

  job_queue = job_queue->next;

  /* выполняем задание. */

  process_job(next_job);

  /* Очистка. */

  free(next_job);

 }

 return NULL;

}

Теперь предположим, что два потока завершают свои операции примерно в одно и то же время, а в очереди остается только одно задание. Первый поток проверяет, равен ли указатель job_queue значению NULL, и, обнаружив, что очередь не пуста, входит в цикл, где сохраняет указатель на объект задания в переменной next_job. В этот момент Linux прерывает первый поток и активизирует второй. Он тоже проверяет указатель job_queue, устанавливает, что он не равен NULL, и записывает тот же самый указатель в свою переменную next_job. Увы, теперь мы имеем два потока, выполняющих одно и то же задание.

Далее ситуация только ухудшается. Первый поток удаляет последнее задание из очереди. делая переменную job_queue равной NULL. Когда второй поток попытается выполнить операцию job_queue->next, возникнет фатальная ошибка сегментации.

Это наглядный пример гонки за ресурсами. Если программе "повезет", система не распланирует потоки именно таким образом и ошибка не проявится. Возможно, только в сильно загруженной системе (или в новой многопроцессорной системе важного клиента!) произойдет "необъяснимый" сбой.

Чтобы исключить возможность гонки, необходимо сделать операции атомарными. Атомарная операция неделима и непрерывна; если она началась, то уже не может быть приостановлена или прервана, пока, наконец, не завершится. Выполнение других операций в это время становится невозможным. В нашем конкретном примере проверка переменной job_queue и удаление задания должны выполняться как одна атомарная операция.

 

4.4.2. Исключающие семафоры

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

Реализация такого решения требует поддержки от операционной системы. В Linux имеется специальное средство, называемое исключающим семафором, или мьютексом (MUTual EXclusion — взаимное исключение). Это специальная блокировка, которую в конкретный момент времени может устанавливать только одни поток. Если исключающий семафор захвачен каким-то потоком, другой поток, обращающийся к семафору, оказывается заблокированным или переведенным в режим ожидания. Как только семафор освобождается, поток продолжает свое выполнение. ОС Linux гарантирует, что между потоками, пытающимися захватить исключающий семафор, не возникнет гонка. Такой семафор может принадлежать только одному потоку, а все остальные потоки блокируются.

Чтобы создать исключающий семафор, нужно объявить переменную типа pthread_mutex_t и передать указатель на нее функции pthread_mutex_init(). Вторым аргументом этой функции является указатель на объект атрибутов семафора. Как и в случае функции pthread_create(), если объект атрибутов пуст, используются атрибуты по умолчанию. Переменная исключающего семафора инициализируется только один раз. Вот как это делается:

pthread_mutex_t mutex;

pthread_mutex_init(&mutex, NULL);

Более простой способ создания исключающего семафора со стандартными атрибутами — присвоение переменной специального значения PTHREAD_MUTEX_INITIALIZER. Вызывать функцию pthread_mutex_init() в таком случае не требуется. Это особенно удобно для глобальных переменных (а в C++ — статических переменных класса). Предыдущий фрагмент программы эквивалентен следующей записи:

pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;

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

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

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

Листинг 4.11. ( job-queue2.c ) Работа с очередью заданий, защищенной исключающим семафором

#include

#include

struct job {

 /* Ссылка на следующий элемент связанного списка. */

 struct job* next;

 /* Другие поля, описывающие требуемую операцию... */

};

/* Список отложенных заданий. */

struct job* job_queue;

/* Исключающий семафор, защищающий очередь. */

pthread_mutex_t job_queue_mutex = PTHREAD_MUTEX_INITIALIZER;

/* Обработка заданий до тех пор, пока очередь не опустеет. */

void* thread_function(void* arg) {

 while (1) {

  struct job* next_job;

  /* Захват семафора, защищающего очередь. */

  pthread_mutex_lock(&job_queue_mutex);

  /* Теперь можно проверить, является ли очередь пустой. */

  if (job_queue == NULL)

   next_job = NULL;

  else {

   /* Запрашиваем следующее задание. */

   next_job = job_queue;

   /* Удаляем задание из списка. */

   job_queue = job_queue->next;

  }

  /* Освобождаем семафор, так как работа с очередью окончена. */

  pthread_mutex_unlock(&job_queue_mutex);

  /* Если очередь пуста, завершаем поток. */

  if (next_job == NULL)

   break;

  /* Выполняем задание. */

  process_job(next_job);

  /* Очистка. */

  free(next_job);

 }

 return NULL;

}

Все операции доступа к совместно используемому указателю job_queue происходят между вызовами функций pthread_mutex_lock() и pthread_mutex_unlock(). Объект задания, ссылка на который хранится в переменной next_job, обрабатывается только после того, как ссылка на него удаляется из очереди, что позволяет обезопасить этот объект от других потоков.

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

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

void enqueue_job(struct job* new_job) {

 pthread_mutex_lock(&job_queue_mutex);

 new_job->next = job_queue;

 job_queue = new_job;

 pthread_mutex_unlock(&job_queue_mutex);

}

 

4.4.3. Взаимоблокировки исключающих семафоров

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

Простейшая тупиковая ситуация — когда один поток пытается захватить тот же самый исключающий семафор дважды подряд. Дальнейшие действия зависят от типа исключающего семафора. Их всего три.

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

■ Захват рекурсивного семафора не приведет к взаимоблокировке. Семафор данного типа запоминает, сколько раз функция pthread_mutex_lock() была вызвана в потоке, которому принадлежит семафор. Чтобы освободить семафор и позволить другим потокам обратиться к нему, необходимо аналогичное число раз вызвать функцию pthread_mutex_unlock().

■ Операционная система Linux обнаруживает попытку повторно захватить контролирующий семафор и сигнализирует об этом: при очередном вызове функции pthread_mutex_lock() возвращается код ошибки EDEADLK.

По умолчанию в Linux создается быстрый семафор. В двух других случаях требуется предварительно создать объект атрибутов семафора, объявив переменную типа pthread_mutexattr_t и передав указатель на нее функции pthread_mutexattr_init(). Затем нужно задать тип исключающего семафора с помощью функции pthread_mutexattr_setkind_np(). Первым ее аргументом является указатель на объект атрибутов семафора; второй аргумент равен PTHREAD_MUTEX_RECURSIVE_NP в случае рекурсивного семафора и PTHREAD_MUTEX_ERRORCHECK_NP — в случае контролирующего семафора. Указатель на полученный объект атрибутов необходимо передать функции pthread_mutex_init(), которая создаст семафор. После этого нужно удалить объект атрибутов с помощью функции pthread_mutexattr_destroy().

Следующий фрагмент программы иллюстрирует процесс создания контролирующего семафора:

pthread_mutexattr_t attr;

pthread_mutex_t mutex;

pthread_mutexattr_init(&attr);

pthread_mutexattr_setkind_np(&attr, PTHREAD_MUTEX_ERRORCHECK_NP);

pthread_mutex_init(&mutex, &attr);

pthread_mutexattr_destroy(&attr);

Как подсказывает префикс "np" (not portable), исключающие семафоры рекурсивного и контролирующего типов специфичны для Linux и непереносимы в другие операционные системы. Поэтому не рекомендуется использовать их в программах широкого назначения.

 

4.4.4. Неблокирующие проверки исключающих семафоров

Иногда нужно, не заблокировав программу, проверить, захвачен ли исключающий семафор. Для потока не всегда приемлемо находиться в режиме пассивного ожидания, ведь за это время можно сделать много полезного! Функция pthread_mutex_lock() не возвращает значения до тех пор, пока семафор не будет освобожден, поэтому она нам не подходит.

То, что нам нужно, — это функция pthread_mutex_trylock(). Если она обнаруживает, что семафор свободен, то захватывает его так же, как и функция pthread_mutex_lock(), возвращая при этом 0. Если же оказывается, что семафор уже захвачен другим потоком, функция pthread_mutex_trylock() не блокирует программу, а немедленно завершается, возвращая код ошибки EBUSY. "Права собственности" другого потока при этом не нарушаются. Можно попытаться захватить семафор позднее.

 

4.4.5. Обычные потоковые семафоры

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

Такой механизм называется семафором. Семафор — это счетчик, используемый для синхронизации потоков. Операционная система гарантирует, что проверка и модификация значения семафора могут быть выполнены безопасно и не приведут к возникновению гонки.

Счетчик семафора является неотрицательным целым числом. Семафор поддерживает две базовые операции.

■ Операция ожидания (wait) уменьшает значение счетчика на единицу. Если счетчик уже равен нулю, операция блокируется до тех пор, пока значение счетчика не станет положительным (вследствие действий, выполняемых другими потоками). После снятия блокировки значение семафора уменьшается на единицу и операция завершается.

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

В Linux имеются две немного отличающиеся реализации семафоров. Та, которую мы опишем ниже, соответствует стандарту POSIX. Такие семафоры применяются для организации взаимодействия потоков. Другая реализация, служащая целям межпроцессного взаимодействия, рассмотрена в разделе 5.2, "Семафоры для процессов". При работе с семафорами необходимо включить в программу файл .

Семафор представляется переменной типа sem_t. Семафор следует предварительно инициализировать с помощью функции sem_init(), передав ей указатель на переменную семафора. Второй параметр этой функции должен быть равен нулю, а третий — это начальное значение счетчика семафора.

Чтобы выполнить операцию ожидания семафора, необходимо вызвать функцию sem_wait(). Функция sem_post() устанавливает семафор. Есть также функция sem_trywait(), реализующая операцию неблокирующего ожидания. Она напоминает функцию pthread_mutex_trylock(): если операция ожидания приведет к блокированию потока из-за того, что счетчик семафора равен нулю, функция немедленно завершается, возвращая код ошибки EAGAIN.

В Linux имеется функция sem_getvalue(), позволяющая узнать текущее значение счетчика семафора. Это значение помещается в переменную типа int, на которую ссылается второй аргумент функции. Не пытайтесь на основании данного значения определять, стоит ли выполнять операцию ожидания или установки, так как это может привести к возникновению гонки: другой поток способен изменить счетчик семафора между вызовами функции sem_getvalue() и какой-нибудь другой функции работы с семафором. Доверяйте только атомарным функциям sem_wait() и sem_post().

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

Листинг 4.12. ( job-queue3.c ) Работа с очередью заданий с применением семафора

#include

#include

#include

struct job {

 /* Ссылка на следующий элемент связанного списка. */

 struct job* next;

 /* Другие поля, описывающие требуемую операцию... */

};

/* Список отложенных заданий. */

struct job* job_queue;

/* Исключающий семафор, защищающий очередь. */

pthread_mutex_t job_queue_mutex =

 PTHREAD_MUTEX_INITIALIZER;

/* Семафор, подсчитывающий число гаданий в очереди. */

sem_t job_queue_count;

/* Начальная инициализация очереди. */

void initialize_job_queue() {

 /* Вначале очередь пуста. */

 job_queue = NULL;

 /* Устанавливаем начальное значение счетчика семафора

    равным 0. */

 sem_init(&job_queue_count, 0, 0);

}

/* Обработка заданий до тех пор, пока очередь не опустеет. */

void* thread_function(void* arg) {

 while (1) {

  struct job* next_job;

  /* Дожидаемся готовности семафора. Если его значение больше

     нуля, значит, очередь не пуста; уменьшаем счетчик на 1.

     В противном случае операция блокируется до тех пор, пока

     в очереди не появится новое задание. */

  sem_wait(&job_queue_count);

  /* Захват исключающего семафора, защищающего очередь. */

  pthread_mutex_lock(&job_queue_mutex);

  /* Мы уже знаем, что очередь не пуста, поэтому без лишней

     проверки запрашиваем новое задание. */

  next_job = job_queue;

  /* Удаляем задание из списка. */

  job_queue = job_queue->next;

  /* освобождаем исключающий семафор, так как работа с

     очередью окончена. */

  pthread_mutex_unlock(&job_queue_mutex);

  /* Выполняем задание. */

  process_job(next_job);

  /* Очистка. */

  free(next_job);

 }

 return NULL;

}

/* Добавление нового задания в начало очереди. */

void enqueue_job(/* Передача необходимых данных... */) {

 struct job* new_job;

 /* Выделение памяти для нового объекта задания. */

 new_job = (struct job*)malloc(sizeof(struct job));

 /* Заполнение остальных полей структуры JOB... */

 /* Захватываем исключающий семафор, прежде чем обратиться

    к очереди. */

 pthread_mutex_lock(&job_queue_mutex);

 /* Помещаем новое задание в начало очереди. */

 new_job->next = job_queue;

 job_queue = new_job;

 /* Устанавливаем семафор, сообщая о том, что в очереди появилось

    новое задание. Если есть потоки, заблокированные в ожидании

    семафора, один из них будет разблокирован и

    обработает задание. */

 sem_post(&job_queue_count);

 /* Освобождаем исключающий семафор. */

 pthread_mutex_unlock(&job_queue_mutex);

}

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

Функция enqueue_job() добавляет новое задание в очередь. Подобно потоковой функции, она захватывает исключающий семафор, перед тем как обратиться к очереди. После добавления задания функция enqueue_job() устанавливает семафор, сообщая потокам о том, что задание доступно. В программе, показанной в листинге 4.12, потоки никогда не завершаются: если задания не поступают в течение длительного времени, все потоки переводятся в режим блокирования функцией sem_wait().

 

4.4.6. Сигнальные (условные) переменные

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

Предположим, требуется написать потоковую функцию, которая входит в бесконечный цикл, выполняя на каждой итерации какие-то действия. Но работа цикла должна контролироваться флагом: действие выполняется только в том случае, когда он установлен.

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

Листинг 4.15. ( spin-condvar.c ) Простейшая реализация сигнальной переменной

#include

int thread_flag;

pthread_mutex_t thread_flag_mutex;

void initialize_flag() {

 pthread_mutex_init(&thread_flag_mutex, NULL);

 thread_flag = 0;

}

/* Если флаг установлен, многократно вызывается функция do_work().

   В противном случае цикл работает вхолостую. */

void* thread_function(void* thread_arg) {

 while (1) {

  int flag_is_set;

  /* Защищаем флаг с помощью исключающего семафора. */

  pthread_mutex_lock(&thread_flag_mutex);

  flag_is_set = thread_flag;

  pthread_mutex_unlock(&thread_flag_mutex);

  if (flag_is_set)

   do_work();

  /* Если флаг не установлен, ничего не делаем. Просто переходим

     на следующую итерацию цикла. */

 }

 return NULL;

}

/* Задаем значение флага равным FLAG_VALUE. */

void set_thread_flag(int flag_value) {

 /* Защищаем флаг с помощью исключающего семафора. */

 pthread_mutex_lock(&thread_flag_mutex);

 thread_flag = flag_value;

 pthread_mutex_unlock(&thread_flag_mutex);

}

Сигнальная переменная позволяет организовать такую проверку, при которой поток либо выполняется, либо блокируется. Как и в случае семафора, поток может ожидать сигнальную переменную. Поток A, находящийся в режиме ожидания, блокируется до тех пор, пока другой поток. Б, не просигнализирует об изменении состояния этой переменной. Сигнальная переменная не имеет внутреннего счетчика, что отличает ее от семафора. Поток А должен перейти в состояние ожидания до того, как поток Б пошлет сигнал. Если сигнал будет послал раньше, он окажется потерянным и поток А заблокируется, пока какой-нибудь поток не пошлет сигнал еще раз.

Вот как можно сделать предыдущую программу более эффективной.

■ Функция thread_function() в цикле проверяет флаг. Если он не установлен, поток переходит в режим ожидания сигнальной переменной.

■ Функция set_thread_flag() устанавливает флаг и сигнализирует об изменении условной переменной. Если функция thread_function() была заблокирована в ожидании сигнала, она разблокируется и снова проверяет флаг.

Но существует одна проблема: возникает гонка между операцией проверки флага и операцией сигнализирования или ожидания сигнала. Предположим, что функция thread_function() проверяет флаг и обнаруживает, что он не установлен. В этот момент планировщик Linux прерывает выполнение данного потока и активизирует главную программу. По стечению обстоятельств программа как раз находится в функции set_thread_flag(). Она устанавливает флаг и сигнализирует об изменении условной переменной. Но поскольку в данный момент нет потока, ожидающего получения этого сигнала (вспомните, что функция thread_function() была прервана перед тем, как перейти в режим ожидания), сигнал окажется потерян. Когда Linux вновь активизирует дочерний поток, он начнет ждать сигнал, который, возможно, никогда больше не придет.

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

■ В цикле необходимо захватить исключающий семафор и прочитать значение флага.

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

■ Если флаг не установлен, одновременно выполняются операции освобождения семафора и перехода в режим ожидания сигнала.

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

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

■ Функция pthread_cond_init() инициализирует сигнальную переменную. Первый ее аргумент — это указатель на объект типа pthread_cond_t. Второй аргумент (указатель на объект атрибутов сигнальной переменной) игнорируется в Linux. Исключающий семафор должен инициализироваться отдельно, как описывалось в разделе 4.4.2, "Исключающие семафоры".

■ Функция pthread_cond_signal() сигнализирует об изменении переменной. При этом разблокируется один из потоков, находящийся в ожидании сигнала. Если таких потоков нет, сигнал игнорируется. Аргументом функции является указатель на объект типа pthread_cond_t.

Похожая функция pthread_cond_broadcast() разблокирует все потоки, ожидающие данного сигнала.

■ Функция pthread_cond_wait() блокирует вызывающий ее поток до тех пор, пока не будет получен сигнал об изменении заданной переменной. Первым ее аргументом является указатель на объект типа pthread_cond_t. Второй аргумент — это указатель на объект исключающего семафора (тип pthread_mutex_t).

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

Перечисленные ниже этапы должны выполняться всякий раз, когда программа тем или иным способом меняет результат проверки условия, контролируемого сигнальной переменной (в нашей программе условие — это значение флага):

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

2. Выполнить действие, включающее изменение результата проверки условия (в нашем случае — установить флаг).

3. Послать сигнал (возможно, широковещательный) об изменении условия.

4. Освободить исключающий семафор.

В листинге 4.14 показана измененная версия предыдущего примера, в которой на этот раз флаг защищается сигнальной переменной. Обратите внимание на то, что в функции thread_function() исключающий семафор захватывается до того, как будет проверено значение переменной thread_flag. Захват автоматически снимается функцией pthread_cond_wait() перед тем, как поток оказывается заблокированным, и также автоматически восстанавливается по завершении функции:

Листинг 4.14. ( condvar.c ) Управление работой потока с помощью сигнальной переменной

#include

int thread_flag;

pthread_cond_t thread_flag_cv;

pthread_mutex_t thread_flag_mutex;

void initialize_flag() {

 /* Инициализация исключающего семафора и сигнальной

    переменной. */

 pthread_mutex_init(&thread_flag_mutex, NULL);

 pthread_cond_init(&thread_flag_cv, NULL);

 /* Инициализация флага. */

 thread_flag = 0;

}

/* Если флаг установлен, многократно вызывается функция

   do_work(). В противном случае поток блокируется. */

void* thread_function(void* thread_arg) {

 /* Бесконечный цикл. */

 while (1) {

  /* Захватываем исключающий семафор, прежде чем обращаться

     к флагу. */

  pthread_mutex_lock(&thread_flag_mutex);

  while (!thread_flag)

   /* Флаг сброшен. Ожидаем сигнала об изменении условной

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

      При поступлении сигнала поток разблокируется и снова

      проверяет флаг. */

   pthread_cond_wait(&thread_flag_cv, &thread_flag_mutex);

  /* При выходе из цикла освобождаем исключающий семафор. */

  pthread_mutex_unlock(&thread_flag_mutex);

  /* Выполняем требуемые действия. */

  do_work();

 }

 return NULL;

}

/* Задаем значение флага равным FLAG_VALUE. */

void set_thread_flag(int flag_value) {

 /* Захватываем исключающий семафор, прежде чем изменять

    значение флага. */

 pthread_mutex_lock(&thread_flag_mutex);

 /* Устанавливаем флаг и посылаем сигнал функции

    thread_function(), заблокированной в ожидании флага.

    Правда, функция не сможет проверить флаг, пока

    исключающий семафор не будет освобожден. */

 thread_flag = flag_value;

 pthread_cond_signal(&thread_flag_cv);

 /* освобождаем исключающий семафор. */

 pthread_mutex_unlock(&thread_flag_mutex);

}

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

Сигнальная переменная может вообще не быть связана ни с каким условием, а служить лишь средством блокирования потока до тех пор, пока какой-нибудь другой поток не "разбудит" его. Для этой же цели может использоваться и семафор. Принципиальная разница между ними заключается в том, что семафор "запоминает" сигнал, даже если ни один поток в это время не был заблокирован, а сигнальная переменная регистрирует сигнал только в том случае, если его ожидает какой-то поток. Кроме того, семафор всегда разблокирует лишь один поток, тогда как с помощью функции pthread_cond_broadcast() можно разблокировать произвольное число потоков.

 

4.4.7. Взаимоблокировки двух и более потоков

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

Чаще всего взаимоблокировка возникает, когда группа потоков пытается захватить один и тот же набор объектов. Рассмотрим, к примеру, программу, в которой два потока, выполняющих разные потоковые функции, должны захватить одни и те же два исключающих семафора. Предположим, ноток А захватывает сначала семафор 1, а затем семафор 2, в то время как поток Б захватывает семафоры в обратном порядке. Возможна достаточно неприятная ситуация, когда после захвата семафора 1 потоком А операционная система активизирует поток Б, который захватит поток 2. Далее оба потока окажутся заблокированными, так как им будет закрыт доступ к семафорам друг друга.

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

 

4.5. Реализация потоков в Linux

 

Потоковые функции, соответствующие стандарту POSIX, реализованы в Linux не так, как в большинстве других версий UNIX. Суть в том, что в Linux потоки реализованы в виде процессов. Когда вызывается функция pthread_create(), операционная система на самом деле создает новый процесс, выполняющий поток. Но это не тот процесс, который создается функцией fork(). Он, в частности, делит общее адресное пространство и ресурсы с исходным процессом, а не получает их копии.

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

Листинг 4.15. ( thread-pid.c ) Вывод идентификаторов потоков

#include

#include

#include

void* thread_function(void* arg) {

 fprintf(stderr, "child thread pid is %d\n", (int) getpid());

 /* Бесконечный цикл. */

 while (1);

 return NULL;

}

int main() {

 pthread_t thread;

 fprintf(stderr, "main thread pid is %d\n", (int)getpid());

 pthread_create(&thread, NULL, &thread_function, NULL);

 /* Бесконечный цикл. */

 while (1);

 return 0;

}

Запустите программу в фоновом режиме, а затем вызовите команду ps x, чтобы увидеть список выполняющихся процессов. Не забудьте затем уничтожить программу thread-pid, так как она потребляет ресурсы процессора. Вот что мы получим:

% cc thread-pid.c -о thread-pid -lpthread

% ./thread-pid &

[1] 14608

main thread pid is 14608

child thread pid is 14610

% ps x

  PID TTY   STAT TIME COMMAND

14042 pts/9 S    0:00 bash

14068 pts/9 R    0:01 ./thread-pid

14069 pts/9 S    0:00 ./thread-pid

14610 pts/9 R    0:01 ./thread-pid

14611 pts/9 R    0:00 ps x

% kill 14608

[1]+ Terminated ./thread-pid

Сообщения интерпретатора команд» касающиеся управления заданиями

Строки, начинающиеся с записи [1] , поступают от интерпретатора команд. Если программа запускается в фоновом режиме, интерпретатор назначает ей номер задания — в данном случае 1 — и сообщает ее идентификатор. Когда фоновое задание завершается, интерпретатор сообщает об этом при вызове первой же команды

Обратите внимание на то, что программе thread-pid соответствуют три процесса. Первый из них, с идентификатором 14608, — это основной поток программы. Третий, с идентификатором 14610, — это дочерний поток, выполняющий функцию thread_function(). Что же такое тогда второй поток, с идентификатором 14609? Это "управляющий поток", являющийся частью внутреннего механизма реализации потоков в Linux. Он создается, когда программа вызывает функцию pthread_create().

 

4.5.1. Обработка сигналов

Предположим, что многопотоковая программа принимает сигнал. В каком потоке будет вызван обработчик сигнала? Это зависит от версии UNIX. В Linux поведение программы объясняется тем. что потоки на самом деле реализуются в виде процессов.

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

Тем не менее подобная особенность реализации библиотеки Pthreads в Linux не согласуется со стандартом POSIX. Нельзя полагаться на нее в программах, рассчитанных на то, чтобы быть переносимыми.

В многопотоковой программе один поток может послать сигнал другому. Для этого предназначена функция pthread_kill(). Ее первым параметром является идентификатор потока, а второй параметр — это номер сигнала.

 

4.5.2. Системный вызов clone()

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

В Linux имеется функция clone(), являющаяся обобщением функций fork() и pthread_create(). Она позволяет вызывающему процессу указывать, какие ресурсы он согласен делить с дочерним процессом. Необходимо также задать область памяти, в которой будет расположен стек выполнения нового процесса. Вообще говоря, мы упоминаем функцию clone() лишь для того, чтобы удовлетворить любопытство читателей. Использовать ее в программах не следует. Создавайте процессы с помощью функции fork(), а потоки — с помощью функции pthread_create().

 

4.6. Сравнение процессов и потоков

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

■ Все потоки программы должны выполнять один и тот же код. В то же время дочерний процесс может запустить другой исполняемый файл с помощью функции exec().

■ Неправильно работающий поток способен помешать другим потокам того же процесса, поскольку все они используют одни и те же ресурсы. Например, неверное обращение к указателю может привести к искажению области памяти, используемой другим потоком. Процесс лишен возможности это делать, так как у него своя копия памяти,

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

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

■ Совместное использование данных несколькими потоками — тривиальная задача, ведь потоки имеют общий доступ к ресурсам (необходимо, правда, внимательно следить за тем, чтобы не возникало состояние гонки). В случае процессов требуется задействовать особый механизм взаимодействия, описанный в главе 5, "Взаимодействие процессов". Это делает программы более громоздкими, зато уменьшает вероятность ошибок, связанных с параллельной работой.

 

Глава 5

Взаимодействие процессов

 

В главе 3, "Процессы", описывалась процедура создания процесса и рассказывалось о том, как родительский процесс может получить код завершения дочернего процесса. Это простейшая форма взаимодействия двух процессов, но не самая эффективная. Рассмотренные в главе 3 механизмы позволяли процессу-предку общаться с процессом-потомком только посредством аргументов командной строки и переменных среды, а все, что мог сделать для предка потомок, — вернуть свой код завершения. Такие механизмы не позволяют контролировать выполняющийся процесс или обращаться к внешнему, независимому процессу.

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

Взаимодействие процессов — это механизм обмена данными между процессами. Взять, к примеру, ситуацию, когда броузер запрашивает Web-страницу у сервера, который в ответ высылает HTML-данные. Обычно при этом используются сокеты, работающие через телефонное соединение. Или другой пример: пользователь вводит команду ls | lpr, чтобы вывести на печать список файлов в каталоге. Интерпретатор команд создает два отдельных процесса — ls и lpr — и соединяет их каналом, который представлен символом '|'. Канал — это однонаправленный способ передачи данных от одного процесса к другому. Процесс ls записывает данные в канал, а процесс lpr читает данные из него.

В этой главе рассматриваются пять способов взаимодействия процессов.

■ Совместно используемая память — процессы могут просто читать и записывать данные в рамках заданной области памяти.

■ Отображаемая память — напоминает совместно используемую память, но организуется связь с файлами.

■ Каналы — позволяют последовательно передавать данные от одного процесса к другому.

■ FIFO-файлы — в отличие от каналов, с ними работают несвязанные процессы, поскольку у такого файла есть имя в файловой системе и к нему может обратиться любой процесс.

■ Сокеты — соединяют несвязанные процессы, работающие на разных компьютерах.

Различия между способами взаимодействия определяются следующими критериями:

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

■ ограничен ли процесс только чтением либо только записью данных;

■ число взаимодействующих процессов;

■ синхронизируются ли взаимодействующие процессы (например, должен ли читающий процесс перейти в режим ожидания при отсутствии данных на входе).

 

5.1. Совместно используемая память

 

Простейшим способом взаимодействия процессов является совместный доступ к общей области памяти. Это выглядит так, как если бы два или более процесса вызвали функцию malloc() и получили указатели на один и тот же блок памяти. Когда один из процессов меняет содержимое памяти, другие процессы замечают это изменение.

 

5.1.1. Быстрое локальное взаимодействие

Совместное использование памяти — самый быстрый способ взаимодействия. Процесс обращается к общей памяти с той же скоростью, что и к своей собственной памяти, и никаких системных вызовов или обращений к ядру не требуется. Устраняется также ненужное копирование данных.

Ядро не синхронизирует доступ процессов к общей памяти — об этом следует позаботиться программисту. Например, процесс не должен читать данные из совместно используемой памяти, пока в нее осуществляется запись, и два процесса не должны одновременно записывать данные в одну и ту же область памяти. Стандартная стратегия предотвращения подобной конкуренции заключается в использовании семафоров, о которых пойдет речь в раздаче 5.2, "Семафоры для процессов". Тем не менее в приводимом далее примере программы доступ к памяти осуществляет только один процесс: просто мы хотим сконцентрировать внимание читателей на механизме совместного использования памяти и не перегружать программу кодом синхронизации.

 

5.1.2. Модель памяти

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

Для того чтобы понять принципы выделения и подключения сегментов памяти, необходимо разобраться в модели памяти Linux. В Linux виртуальная память (ВП) каждого процесса разбита на страницы. Все процессы хранят таблицу соответствий между своими адресами памяти и страницами ВП, содержащими реальные данные. Несмотря на то что за каждым процессом закреплены свои адреса, разным процессам разрешается ссылаться на одни и те же страницы. Это и есть совместное использование памяти.

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

Размер совместно используемого сегмента кратен размеру страницы ВП. В Linux последняя величина обычно равна 4 Кбайт, но никогда не помешает это проверить с помощью функции getpagesize().

 

5.1.3. Выделение сегментов памяти

Процесс выделяет сегмент памяти с помощью функции shmget(). Первым аргументом функции является целочисленный ключ, идентифицирующий создаваемый сегмент. Если несвязанные процессы хотят получить доступ к одному и тому же сегменту, они должны указать одинаковый ключ. К сожалению, ничто не мешает посторонним процессам выбрать тот же самый ключ сегмента, а это приведет к системному конфликту. Указание специальной константы IPC_PRIVATE в качестве ключа позволяет гарантировать, что будет создан совершенно новый сегмент.

Во втором аргументе функции задается размер сегмента в байтах. Это значение округляется, чтобы быть кратным размеру страницы ВП.

Третий параметр содержит набор битовых флагов. Перечислим наиболее важные из них.

■ IPC_CREAT. Указывает на то, что создается новый сегмент, которому присваивается заданный ключ.

■ IPC_EXCL. Всегда используется совместно с флагом IPC_CREAT и заставляет функцию shmget() выдать ошибку в случае, когда сегмент с указанным ключом уже существует. Если флаг не указан и возникает описанная ситуация, функция shmget() возвращает идентификатор существующего сегмента, не создавая новый сегмент.

■ Флаги режима. В эту группу входят 9 флагов, задающих права доступа к сегменту для владельца, группы и остальных пользователей. Биты выполнения игнорируются. Проще всего задавать права доступа с помощью констант, определенных в файле (они описаны на man-странице функции stat()). Например, флаги S_IRUSR и S_IWUSR предоставляют право чтения и записи владельцу сегмента, а флаги S_IROTH и S_IWOTH предоставляют аналогичные права остальным пользователям.

В следующем фрагменте программы функция shmget() создает новый совместно используемый сегмент памяти (или возвращает идентификатор существующего, если значение shm_key уже зарегистрировано в системе), доступный для чтения/записи только его владельцу:

int segment_id = shmget(shm_key, getpagesize(),

 IPC_CREAT | S_IRUSR | S_IWUSR);

В случае успешного завершения функция возвращает идентификатор сегмента. Если сегмент уже существует, проверяются нрава доступа к нему.

 

5.1.4. Подключение и отключение сегментов

Чтобы сделать сегмент памяти общедоступным, процесс должен подключить его с помощью функции shmat(). В первом ее аргументе передается идентификатор сегмента, возвращенный функцией shmget(). Второй аргумент — это указатель, определяющий, где в адресном пространстве процесса необходимо создать привязку на совместно используемую область памяти. Если задать значение NULL, ОС Linux выберет первый доступный адрес. Третий аргумент может содержать следующие флаги.

■ SHM_RND. Указывает на то, что адрес, заданный во втором параметре, должен быть округлен, чтобы стать кратным размеру страницы. Если этот флаг не указан, необходимо самостоятельно позаботиться о выравнивании сегмента по границе страницы.

■ SHM_RDONLY. Указывает на то. что сегмент доступен только для чтения, но не для записи.

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

По завершении работы с сегментом его необходимо отключить с помощью функции shmdt(). Ей следует передать адрес, возвращаемый функцией shmat(). Если текущий процесс был последним, кто ссылался на сегмент, сегмент удаляется из памяти. Функции exit() и exec() автоматически отключают сегменты.

 

5.1.5. Контроль и освобождение совместно используемой памяти

Функция shmctl() возвращает информацию о совместно используемом сегменте и способна модифицировать его. Первым параметром является идентификатор сегмента.

Чтобы получить информацию о сегменте, укажите в качестве второго параметра константу IPC_STAT, а в третьем параметре передайте указатель на структуру shmid_ds.

Чтобы удалить сегмент, передайте во втором параметре константу IPC_RMID, а в третьем параметре — NULL. Сегмент удаляется, когда последний подключивший его процесс отключает сегмент.

Каждый совместно используемый сегмент должен явно освобождаться с помощью функции shmctl(), чтобы случайно не был превышен системный лимит на общее число таких сегментов. Функции exit() и exec() отключают сегменты, но не освобождают их.

Описание других операций, выполняемых над совместно используемыми сегментами памяти, можно найти на man-странице функции shmctl().

 

5.1.6. Пример программы

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

Листинг 5.1. ( shm.c ) Пример совместного использования памяти

#include

#include

#include

int main() {

 int segment_id;

 char* shared_memory;

 struct shmid_ds shmbuffer;

 int segment_size;

 const int shared_segment_size = 0x6400;

 /* Выделение совместно используемого сегмента. */

 segment_id =

  shmget(IPC_PRIVATE, shared_segment_size,

  IPC_CREAT | IPC_EXCL | S_IRUSR | S_IWUSR);

 /* Подключение сегмента. */

 shared_memory = (char*)shmat(segment_id, 0, 0);

 printf("shared memory attached at address %p\n",

  shared_memory);

 /* Определение размера сегмента. */

 shmctl(segment_id, IPC_STAT, &shmbuffer);

 segment_size = shmbuffer.shm_segsz;

 printf("segment size: %d\n", segment_size);

 /* Запись строки в сегмент. */

 sprintf(shared_memory, "Hello, world.");

 /* Отключение сегмента. */

 shmdt(shared_memory);

 /* Повторное подключение сегмента, но по другому адресу! */

 shared_memory =

  (char*)shmat(segment_id, (void*) 0x5000000, 0);

 printf("shared memory reattached at address %p\n",

  shared_memory);

 /* Отображение строки, хранящейся в совместно используемой

    памяти. */

 printf("%s\n", shared_memory);

 /* Отключение сегмента. */

 shmdt(shared_memory);

 /* Освобождение сегмента. */

 shmctl(segment_id, IPC_RMID, 0);

 return 0;

}

 

5.1.7. Отладка

Команда ipcs выдает информацию о взаимодействии процессов, включая сведения о совместно используемых сегментах (для этого следует задать флаг -m). Например, в показанном ниже случае сообщается о том, что используется один такой сегмент, с номером 1627649:

% ipcs -m

-------- Shared Memory Segments --------

key        shmid   owner perms bytes nattch status

0x00000000 1627649 user  640   25600 0

Если этот сегмент был по ошибке "забыт" какой-то программой, его можно удалить с помощью команды ipcrm:

% ipcrm shm 1627649

 

5.1.8. Проблема выбора

Благодаря совместному использованию памяти можно организовать быстрое двустороннее взаимодействие произвольного числа процессов. Любой пользователь сможет получать доступ к сегментам памяти для чтения/записи, но для этого программа должна следовать определенным правилам, позволяющим избегать конкуренции (чтобы, например, информация не оказалась перезаписанной до того, как будет прочитана). К сожалению, Linux не гарантирует монопольный доступ к сегменту, даже если он был создан с указанием флага IPC_PRIVATE.

Кроме того, чтобы несколько процессов могли совместно работать с общим сегментом, они должны "договориться" о выборе одинакового ключа.

 

5.2. Семафоры для процессов

 

Как говорилось в предыдущем разделе, процессы должны координировать свои усилия при совместном доступе к памяти. Вспомните: в разделе 4.4.5, "Обычные потоковые семафоры", рассказывалось о семафорах, которые являются счетчиками, позволяющими синхронизировать работу потоков. В Linux имеется альтернативная реализация семафоров (иногда называемых семафорами System V), предназначенных для синхронизации процессов. Такие семафоры выделяются, используются и освобождаются подобно совместно используемым сегментам памяти. Для большинства случаев достаточно одного семафора, тем не менее они работают группами. В этом разделе мы опишем системные вызовы, позволяющие реализовать двоичный семафор.

 

5.2.1. Выделение и освобождение семафоров

Функции semget() и semctl() выделяют и освобождают семафоры, функционируя подобно функциям shmget() и shmctl(). Первым аргументом функции semget() является ключ, идентифицирующий группу семафоров; второй аргумент — это число семафоров в группе; третий аргумент — флаги прав доступа, как в функции shmget(). Функция semget() возвращает идентификатор группы семафоров. Если задан ключ, принадлежащий существующей группе, будет возвращен ее идентификатор. В этом случае второй аргумент (число семафоров) может равняться нулю.

Семафоры продолжают существовать даже после того, как все работавшие с ними процессы завершились. Чтобы система не исчерпала лимит семафоров, последний процесс должен явно удалить группу семафоров. Для этого нужно вызвать функцию semctl(), передав ей идентификатор группы, число семафоров в группе, флаг IPC_RMID и произвольное значение типа union semun (оно игнорируется). Значение EUID (эффективный идентификатор пользователя) процесса, вызвавшего функцию, должно совпадать с аналогичным значением процесса, создавшего группу семафоров (либо вызывающий процесс должен быть запущен пользователем root). В отличие от совместно используемых сегментов памяти, удаляемая группа семафоров немедленно освобождается.

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

Листинг 5.2. ( sem_all_deall.c ) Выделение и освобождение двоичного семафора

#include

#include

#include

/* Тип union semun необходимо определить самостоятельно. */

union semun {

 int val;

 struct semid_ds *buf;

 unsigned short int* array;

 struct seminfo *__buf;

};

/* Получаем идентификатор семафора и создаем семафор,

   если идентификатор оказывается уникальным. */

int binary_semaphore_allocation(key_t key, int sem_flags) {

 return semget(key, 1, sem_flags);

}

/* Освобождаем семафор, подразумевая, что пользователи

   больше не работают с ним. В случае ошибки

   возвращается -1. */

int binary_semaphore_deallocate(int semid) {

 union semun ignored_argument;

 return semctl(semid, 1, IPC_RMID, ignored_argument}

}

 

5.2.2. Инициализация семафоров

Выделение и инициализация семафора — две разные операции. Чтобы проинициализировать семафор, вызовите функцию semctl(), задав второй аргумент равным нулю, а третий аргумент — равным константе SETALL. Четвертый аргумент должен иметь тип union semun, поле array которого указывает на массив значений типа unsigned short. Каждое значение инициализирует один семафор из набора.

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

Листинг 5.3. ( sem_init.c ) Инициализация двоичного семафора

#include

#include

#include

/* Тип union semun необходимо определить самостоятельно. "/

union semun {

 int val;

 struct semid_ds* buf;

 unsigned short int *array;

 struct seminfo *__buf;

};

/* Инициализация двоичного семафора значением 1. */

int binary_semaphore_initialize(int semid) {

 union semun argument;

 unsigned short values(1);

 values[0] = 1;

 argument.array = values;

 return semctl(semid, 0, SETALL, argument);

}

 

5.2.3. Операции ожидания и установки

Каждый семафор имеет неотрицательное значение и поддерживает операции ожидания и установки. Системный вызов semop() реализует обе операции. Первым аргументом функции является идентификатор группы семафоров. Второй аргумент — это массив значений типа struct sembuf, задающих выполняемые операции. Третий аргумент — это длина массива.

Ниже перечислены поля структуры sembuf.

■ sem_num — номер семафора в группе.

■ sem_op — число, задающее операцию.

Если данное поле содержит положительное число, оно немедленно добавляется к значению семафора.

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

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

■ sem_flg — это значение флага. Флаг IPC_NOWAIT предотвращает блокирование операции. Если запрашиваемая операция приведет к блокированию, функция semop() завершится выдачей кода ошибки. При наличии флага SEM_UNDO ОС Linux автоматически отменит выполненную операцию по завершении процесса.

В листинге 5.4 иллюстрируются операции ожидания и установки двоичного семафора.

Листинг 5.4. ( sem_pv.c ) Ожидание и установка двоичного семафора

#include

#include

#include

/* Ожидание семафора. Операция блокируется до тех пор, пока

   значение семафора не станет положительным, после чего

   значение уменьшается на единицу. */

int binary_semaphore_wait(int semid) {

 struct sembuf operations[1];

 /* Оперируем одним-единственным семафором. */

 operations[0].sem_num = 0;

 /* Уменьшаем его значение на единицу. */

 operations[0].sem_op = -1;

 /* Разрешаем отмену операции. */

 operations[0].sem_flg = SEM_UNDO;

 return semop(semid, operations, 1);

}

/* Установка семафора: его значение увеличивается на единицу.

   Эта операция завершается немедленно. */

int binary_semaphore_post(int semid) {

 struct sembuf operations[1];

 /* оперируем одним-единственным семафором. */

 operations[0].sem_num = 0;

 /* Увеличиваем его значение на единицу. */

 operations[0].sem_op = 1;

 /* Разрешаем отмену операции. */

 operations[0].sem_flg = SEM_UNDO;

 return semop(semid, operations, 1);

}

Флаг SEM_UNDO позволяет решить проблему, возникающую при завершении процесса, которого есть ресурсы, связанные с семафором. Как бы ни завершился процесс — принудительно или естественным образом, — значение семафора автоматически корректируется. "отменяя" эффект операции, выполненной над семафором. Например, если процесс уменьшил значение семафора, а затем был уничтожен командой kill, значение семафора будет снова увеличено.

 

5.2.4. Отладка семафоров

С помощью команды ipcs -s можно получить информацию о существующих группах семафоров. Команда ipcrm sem позволяет удалить заданную группу, например:

% ipcrm sem 5790517

 

5.3. Отображение файлов в памяти

 

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

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

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

Файлы, отображаемые в памяти, можно использовать не только для организации взаимодействия процессов. О других применениях таких файлов пойдет речь в разделе 5.3.5. "Другие применения функции mmap()".

 

5.3.1. Отображение в памяти обычного файла

Для отображения обычного файла в памяти процесса предназначена функция mmap(). Ее первым аргументом является адрес, который будет соответствовать началу отображаемого файла в адресном пространстве процесса. Если задать значение NULL, ОС Linux выберет первый доступный адрес. Второй аргумент — это длина отображаемой области в байтах. Третий аргумент задает степень защиты диапазона отображаемых адресов. Он может содержать объединение битовых констант PROT_READ, PROT_WRITE и PROT_EXEC, соответствующих разрешению на чтение, запись и выполнение соответственно. Четвертый аргумент содержит дополнительные флаги. Пятый аргумент — это дескриптор открытого файла. В последнем аргументе задается смещение от начала файла, с которого начинается отображаемая область. Можно перенести в память весь файл или только часть его, должным образом корректируя начальное смещение и длину отображаемой области.

Ниже перечислены дополнительные флаги, задаваемые в четвертом аргументе.

■ MAP_FIXED. При наличии этого флага ОС Linux использует значение первого аргумента как точный адрес размещения отображаемого файла. Этот адрес должен соответствовать началу страницы.

■ MAP_PRIVATE. Изменения, вносимые в отображаемую память, записываются не в присоединенный файл, а в частную копию файла, принадлежащую процессу. Другие процессы не узнают об этих изменениях. Данный режим не совместим с режимом MAP_SHARED.

■ MAP_SHARED. Изменения, вносимые в отображаемую память, немедленно фиксируются в файле, минуя буфер. Этот режим используется при организации взаимодействия процессов и не совместим с режимом MAP_PRIVATE.

При успешном завершении функция возвращает указатель на начало области памяти. В противном случае возвращается флаг MAP_FAILED.

По окончании работы с отображаемым файлом его необходимо освободить с помощью функции munmap(). Ей передается начальный адрес и длина отображаемой области. ОС Linux автоматически освобождает отображаемые области при завершении процесса.

 

5.3.2. Примеры программ

В этом разделе рассматриваются две программы, в которых иллюстрируются чтение и запись файлов, отображаемых в памяти. Первая программа (листинг 5.5) генерирует случайное число и записывает его в отображаемый файл. Вторая программа (листинг 5.6) читает число из файла, выводит его на экран, а затем умножает на 2 и записывает обратно в файл. Обе программы принимают имя файла из командной строки.

Листинг 5.5. ( mmap-write.c ) Запись случайного числа в файл, отображаемый в памяти

#include

#include

#include

#include

#include

#include

#include

#define FILE_LENGTH 0x100

/* получение случайного числа в диапазоне [low,high]. */

int random_range(unsigned const low, unsigned const high) {

 unsigned const range = high - low + 1;

 return

  low + (int)(((double)range) * rand() / (RAND_MAX + 1.0));

}

int main (int argc, char* const argv[]) {

 int fd;

void* file_memory;

 /* Инициализация генератора случайных чисел. */

 srand(time(NULL));

 /* подготовка файла, размер которого будет достаточен для

    записи беззнакового целого числа. */

 fd = open(argv[1], O_RDWR | O_CREAT, S_IRUSR | S_IWUSR);

 lseek(fd, FILE_LENGTH+1, SEEK_SET);

 write(fd, "", 1);

 lseek(fd, 0, SEEK_SET);

 /* Создание отображаемой области. */

 file_memory =

  mmap(0, FILE_LENGTH, PROT_WRITE, MAP_SHARED, fd, 0);

 close(fd);

 /* Запись случайного числа в отображаемую память. */

 sprintf((char*)file_memory,

  "%d\n", random_range(-100, 100));

 /* Освобождение памяти (не обязательно, так как программа

    завершается). */

 munmap(file_memory, FILE_LENGTH);

 return 0;

}

Программа mmap-write пытается открыть файл и, если он не существует, создает его. Третий аргумент функции open() указывает на то, что файл доступен для чтения/записи. Поскольку длина файла неизвестна, с помощью функции lseek() мы убеждаемся в том, что файл имеет достаточную длину для записи беззнакового целого числа, а затем возвращаемся в начало файла.

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

Листинг 5.6. ( mmap-read.c ) Чтение случайного числа из файла, отображаемого в памяти

#include

#include

#include

#include

#include

#include

#define FILE_LENGTH 0x100

int main(int argc, char* const argv[]) {

 int fd;

 void* file_memory;

 int integer;

 /* Открытие файла. */

 fd = open(argv[1], O_RDWR, S_IRUSR | S_IWUSR);

 /* Создание отображаемой области. */

 file_memory =

  mmap(0, FILE_LENGTH, PROT_READ | PROT_WRITE,

  MAP_SHARED, fd, 0);

 close(fd);

 /* Чтение целого числа и вывод его на экран. */

 sscanf(file_memory, "%d", &integer);

 printf("value: %d\n", integer);

 /* Удваиваем число и записываем его обратно в файл. */

 sprintf((char*)file_memory, "%d\n", 2 * integer);

 /* Освобождение памяти (не обязательно, так как программа

    завершается). */

 munmap(file_memory, FILE_LENGTH);

 return 0;

}

Программа mmap-read читает число из файла, а затем удваивает его и записывает обратно в файл. Сначала файл открывается для чтения/записи. Поскольку предполагается, что файл содержит число, проверка с помощью функции lseek(), как в предыдущей программе, не требуется. Чтение содержимого памяти и его анализ выполняет функция lseek(). Функция sprintf() форматирует число и записывает его в память.

Ниже показан пример запуска обеих программ. Им на вход передается файл /tmp/integer-file.

% ./mmap-write /tmp/integer-file

% cat /tmp/integer-file

42

% ./mmap-read /tmp/integer-file

value: 42

% cat /tmp/integer-file

84

Обратите внимание: значение 42 оказалось записано в файл на диске, хотя функция write() не вызывалась. Последующее чтение файла осуществлялось без функции read(). Целое число записывалось в файл и извлекалось из него в текстовом виде (с помощью функций sprintf() и sscanf()). Это сделано исключительно в демонстрационных целях. В действительности отображаемый файл может содержать не только текст, но и двоичные данные.

 

5.3.3. Совместный доступ к файлу

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

С другой стороны, с помощью функции msync() можно заставить операционную систему перенести содержимое буфера в дисковый файл. Первые два параметра этой функции такие же, как и в функции munmap(). Третий параметр может содержать следующие флаги.

■ MS_ASYNC. Операция обновления ставится в очередь планировщика и будет выполнена, но не обязательно до того, как функция завершится.

■ MS_SYNC. Операция обновления выполняется немедленно. До ее завершения функция блокируется. Флаги MS_ASYNC и MS_SYNC нельзя указывать одновременно.

■ MS_INVALIDATE. Все остальные отображаемые области помечаются как недействительные и подлежащие обновлению.

Следующая функция обновляет файл, область отображения которого начинается с адреса mem_addr и имеет длину mem_length:

msync(mem_addr, mem_length, MS_SYNC | MS_INVALIDATE);

Как и в случае совместного использования сегментов памяти, при работе с отображаемыми областями необходимо придерживаться определенного порядка во избежание конкуренции. Например, можно создать семафор, который позволит только одному процессу обращаться к отображаемой памяти в конкретный момент времени. Можно также воспользоваться функцией fcntl() и поставить на файл блокировку чтения или записи (об этом рассказывается в разделе 8.3, "Функция fcntl(): блокировки и другие операции над файлами").

 

5.3.4. Частные отображаемые области

Если в функции mmap() указан флаг MAP_PRIVATE, отображаемая область создается в режиме "копирование при записи". Любые операции записи в эту область имеют эффект только в адресном пространстве текущего процесса. Другие процессы, связанные с тем же самым отображаемым файлом, не узнают об изменениях. Изменения заносятся не на страницу, доступную всем процессам, а в частную копию этой страницы. Все последующие операции чтения и записи в данном процессе будут выполняться по отношению к этой копии.

 

5.3.5. Применения функции mmap()

Функция mmap() может использоваться не только для организации взаимодействия процессов. Часто она выступает в качестве замены функциям read() и write(). Например, вместо того чтобы непосредственно загружать содержимое файла в память, программа может связать файл с отображаемой памятью и сканировать его путем обращения к памяти. Иногда это удобнее и быстрее, чем выполнять операции файлового ввода-вывода.

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

Другой удобный прием — отображение в памяти файла /dev/zero (описывается в разделе 6.5.2, "/dev/zero"). Этот файл ведет себя так, как будто содержит бесконечное число нулевых байтов. Операции записи в него игнорируются. Описываемый прием часто применяется в пользовательских функциях выделения памяти, которым необходимо инициализировать блоки памяти.

 

5.4. Каналы

 

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

В интерпретаторе команд канал создается оператором |. Например, показанная ниже команда заставляет интерпретатор запустить два дочерних процесса, один — для программы ls, а второй — для программы less:

% ls | less

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

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

 

5.4.1. Создание каналов

Канал создается с помощью функции pipe(). Ей необходимо передать массив из двух целых чисел. В элементе с индексом 0 функция сохраняет дескриптор файла, соответствующего выходному концу канала, а в элементе с индексом 1 сохраняется дескриптор файла, соответствующего входному концу канала. Рассмотрим следующий фрагмент программы

int pipe_fds[2];

int read_fd;

int write_fd;

pipe(pipe_fds);

read_fd = pipe_fds[0];

write_fd = pipe_fds[1];

Данные, записываемые в файл write_fd, могут быть прочитаны из файла read_fd.

 

5.4.2. Взаимодействие родительского и дочернего процессов

Функция pipe() создает два файловых дескриптора, которые действительны только в текущем процессе и его потомках. Эти дескрипторы нельзя передать постороннему процессу. Дочерний процесс получает копии дескрипторов после завершения функции fork().

В программе, показанной в листинге 5.7. родительский процесс записывает в канал строку, а дочерний процесс читает ее. С помощью функции fdopen() файловые дескрипторы приводятся к типу FILE*. Благодаря этому появляется возможность использовать высокоуровневые функции ввода-вывода, такие как printf() и fgets().

Листинг 5.7. ( pipe.c ) Общение с дочерним процессом посредством канала

#include

#include

#include

/* Запись указанного числа копий (COUNT) сообщения (MESSAGE)

   в поток (STREAM) с паузой между каждой операцией. */

void writer(const char* message, int count, FILE* stream) {

 for (; count > 0; --count) {

 /* Запись сообщения в поток с немедленным "выталкиванием"

    из буфера. */

 fprintf(stream, "%s\n", message);

 fflush(stream);

 /* Небольшая пауза. */

 sleep(1);

}

/* Чтение строк из потока, пока он не опустеет. */

void reader(FILE* stream) {

 char buffer[1024];

 /* Чтение данных, пока не будет обнаружен конец потока.

    Функция fgets() завершается, когда встречает символ

    новой строки или признак конца файла. */

 while (!feof(stream)

  && !ferror(stream)

  && fgets(buffer, sizeof (buffer), stream) != NULL)

  fputs(buffer, stdout);

}

int main() {

 int fds[2];

 pid_t pid;

 /* Создание канала. Дескрипторы обоих концов канала

    помещаются в массив FDS. */

 pipe(fds);

 /* порождение дочернего процесса. */

 pid = fork();

 if (pid == (pid_t)0) {

  FILE* stream;

  /* Это дочерний процесс. Закрываем копию входного конца

     канала. */

  close(fds[1]);

  /* Приводим дескриптор выходного конца канала к типу FILE*

     и читаем данные из канала. */

  stream = fdopen(fds[0], "r");

  reader(stream);

  close(fds[0]);

 } else {

  /* Это родительский процесс. */

  FILE* stream;

  /* Закрываем копию выходного конца канала. */

  close(fds[0]);

  /* Приводим дескриптор входного конца канала к типу FILE*

     и записываем данные в канал. */

  stream = fdopen(fds[1], "w");

  writer("Hello, world.", 5, stream);

  close(fds[1]);

 }

 return 0;

}

Сначала в программе объявляется массив fds, состоящий из двух целых чисел. Функция pipe() создает канал и помещает в массив дескрипторы входного и выходного концов канала. Затем функция fork() порождает дочерний процесс. После закрытия выходного конца канала родительский процесс начинает записывать строки в канал. Дочерний процесс читает строки из канала, предварительно закрыв его входной конец.

Обратите внимание на то. что в функции writer() родительский процесс принудительно "выталкивает" буфер канала, вызывая функцию fflush(). Без этого строка могла бы ""застрять" в буфере и отправиться в канал только после завершения родительского процесса.

При вызове команды ls | less функция fork() выполняется дважды: один раз — для дочернего процесса ls, второй раз — для дочернего процесса less. Оба процесса наследуют копии дескрипторов канала, поэтому могут общаться друг с другом. О соединении несвязанных процессов речь пойдет ниже, в разделе 5.4.5, "Каналы FIFO".

 

5.4.3. Перенаправление стандартных потоков ввода, вывода и ошибок

Часто требуется создать дочерний процесс и сделать один из концов канала его стандартным входным или выходным потоком. В этом случае на помощь приходит функция dup2(), которая делает один файловый дескриптор равным другому. Вот как, например, можно связать стандартный входной поток с файлом fd:

dup2(fd, STDIN_FILENO);

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

Программа, представленная в листинге 5.8, с помощью функции dup2() соединяет выходной. Конец канала со входом команды sort. После создания канала программа "делится" функцией fork() на два процесса. Родительский процесс записывает в канал различные строки, а дочерний процесс соединяет выходной конец канала со своим входным потоком, после чего запускает команду sort.

Листинг 5.8. ( dup2.c ) Перенаправление выходного потока канала с помощью функции dup2()

#include

#include

#include

#include

int main() {

 int fds[2];

 pid_t pid;

 /* Создание канала. Дескрипторы обоих концов канала

    помещаются в массив FDS. */

 pipe (fds);

 /* Создание дочернего процесса. */

 pid = fork();

 if (pid == (pid_t)0) {

  /* Это дочерний процесс. Закрываем копию входного конца

    канала */

  close(fds[1]);

  /* Соединяем выходной конец канала со стандартным входным

     потоком. */

  dup2(fds[0], STDIN_FILENO);

  /* Замещаем дочерний процесс программой sort. */

  execlp("sort", "sort", 0);

 } else {

  /* Это родительский процесс. */

  FILE* stream;

  /* Закрываем копию выходного конца канала. */

  close(fds[0]);

  /* Приводим дескриптор входного конца канала к типу FILE*

     и записываем данные в канал. */

  stream = fdopen(fds[1], "w");

  fprintf(stream, "This is a test.\n");

  fprintf(stream, "Hello, world.\n");

  fprintf(stream, "My dog has fleas.\n");

  fprintf(stream, "This program is great.\n");

  fprintf(stream, "One fish, two fish.\n");

  fflush(stream);

  close(fds[1]);

  /* Дожидаемся завершения дочернего процесса. */

  waitpid(pid, NULL, 0);

 }

 return 0;

}

 

5.4.4. Функции popen() и pclose()

Каналы часто используются для передачи данных программе, выполняющейся как подпроцесс (или приема данных от нее). Специально для этих целей предназначены функции popen() и pclose(), устраняющие необходимость в вызове функций pipe(), dup2(), exec() и fdopen().

Сравните листинг 5.9 с предыдущим примером (листинг 5.8).

Листинг 5.9. ( popen.c ) Использование функций popen() и pclose()

#include

#include

int main() {

 FILE* stream = popen("sort", "w");

 fprintf(stream, "This is a test.\n");

 fprintf(stream, "Hello, world.\n");

 fprintf(stream, "My dog has fleas\n");

 fprintf(stream, "This program is great.\n");

 fprintf(stream, "One fish, two fish.\n");

 return pclose(stream);

}

Функция popen() создает дочерний процесс, в котором выполняется команда sort. Один этот вызов заменяет вызовы функций pipe(), fork(), dup2() и execlp(). Второй аргумент, "w", указывает на то, что текущий процесс хочет осуществлять запись в дочерний процесс. Функция popen() возвращает указатель на один из концов канала; второй конец соединяется со стандартным входным потоком дочернего процесса. Функция pclose() закрывает входной поток дочернего процесса, дожидается его завершения и возвращает код статуса.

Первый аргумент функции popen() является командой интерпретатора, выполняемой в подпроцессе /bin/sh. Интерпретатор просматривает переменную среды PATH, чтобы определить, где следует искать команду. Если второй аргумент равен "r", функция возвращает указатель на стандартный выходной поток дочернего процесса, чтобы программа могла читать данные из него. Если второй аргумент равен "w", функция возвращает указатель на стандартный входной поток дочернего процесса, чтобы программа могла записывать данные в него. В случае ошибки возвращается пустой указатель.

Функция pclose() закрывает поток, указатель на который был возвращен функцией popen(), и дожидается завершения дочернего процесса.

 

5.4.5. Каналы FIFO

Файл FIFO (First-In, First-Out — первым пришел, первым обслужен) — это канал, у которого есть имя в файловой системе. Любой процесс может открыть и закрыть такой файл. Процессы, находящиеся на противоположных концах канала, не обязаны быть связанными друг с другом. FIFO-файлы называют именованными каналами.

FIFO-файл создается с помощью команды mkfifo. Путь к файлу указывается в командной строке, например:

% mkfifo /tmp/fifo

% ls -l /tmp/fifo

prw-rw-rw- 1 samuel users 0 Jan 16 14:04 /tmp/fifo

Первый символ в строке режима (p) указывает на то, что файл имеет тип FIFO (именованный канал). Теперь в одном терминальном окне можно осуществлять чтение из файла с помощью команды

% cat < /tmp/fifo

а в другом окне можно выполнять запись в файл:

% cat > /tmp/fifo

Попробуйте во втором окне ввести какой-то текст и нажать . Введенный текст немедленно отобразится в первом окне. Канал закрывается нажатием клавиш во втором окне. FIFO-файл удаляется с помощью следующей команды:

% rm /tmp/fifo

Создание FIFO-файла

FIFO-файл можно создать программным путем с помощью функции mkfifo(). Первым аргументом является путь к файлу. Второй аргумент задает права доступа к каналу со стороны его владельца, группы и остальных пользователей (об этом пойдет речь в разделе 10.3, "Права доступа к файлам"). Поскольку у канала есть читающая и записывающая стороны, права доступа должны учитывать оба случая. Если канал не может быть создан (например, файл с таким именем уже существует), функция mkfifo() возвращает -1. Для работы функции требуется подключить к программе файлы и .

Доступ к FIFO-файлу

К FIFO-файлу можно обращаться как к обычному файлу. При организации межзадачного взаимодействия одна программа должна открыть файл для записи, а другая - для чтения. Над файлом можно выполнять как низкоуровневые (open(), write(), read(), close() и др.), так и высокоуровневые (fopen(), fprintf(), fscanf(), fclose() и др.) функции.

Например, на низком уровне запись блока данных в FIFO-файл осуществляется следующим образом:

int fd = open(fifo_path, O_WRONLY);

write(fd, data, data_length);

close(fd);

А так выполняется чтение строки из FIFO-файла на высоком уровне:

FILE* fifo = fopen(fifo_path, "r");

fscanf(fifo, "%s", buffer);

fclose(fifo);

У FIFO-файла одновременно может быть несколько читающих и записывающих программ. Входные потоки разбиваются на атомарные блоки, размер которых определяется константой PIPE_BUF (4 Кбайт в Linux). Если несколько программ параллельно друг другу осуществляют запись в файл, их блоки будут чередоваться. То же самое относится к программам. одновременно читающим данные из файла.

Отличия от именованных каналов в Windows

Каналы операционных систем семейства Win32 очень напоминают каналы Linux. Основное различие касается именованных каналов, которые в Win32 функционируют скорее как сокеты. Именованные каналы Win32 способны соединять по сети процессы, выполняющиеся на разных компьютерах. В Linux для этой цели используются именно сокеты. Кроме того, в Win32 допускается, чтобы несколько программ чтения или записи работали с именованным каналом, не перекрывая потоки друг друга, а сами каналы поддерживают двунаправленный обмен данными.

 

5.5. Сокеты

 

Сокет — это устройство двунаправленного взаимодействия, которое предназначено для связи с другим процессом, выполняющимся на этом же или на другом компьютере. Сокеты используются Internet-программами, такими как telnet, rlogin, ftp, talk и Web-броузеры.

Например, с помощью программы telnet можно получить от Web-сервера HTML-страницу, поскольку обе программы общаются по сети при помощи сокетов. Чтобы установить соединение с Web-сервером www.codesourcery.com, следует ввести команду telnet www.codesourcery.com 80. Загадочная константа 80 обозначает порт, который прослушивается Web-сервером. Когда соединение будет установлено, введите команду GET /. В результате через сокет будет послан запрос Web-серверу, который в ответ вернет начальную HTML-страницу, после чего закроет соединение.

% telnet www.codesourcery.com 80

Trying 206.168.99.1...

Connected to merlin.codesourcery.com (206.168.99.1).

Escape character is '^]'.

GET /

 

     charset="iso-8659-1">

...

 

5.5.1. Концепции сокетов

При создании сокета необходимо задать три параметра, тип взаимодействия, пространство имен и протокол.

Тип взаимодействия определяет способ интерпретации передаваемых данных и число абонентов. Данные, посылаемые через сокет, формируются в блоки, называемые пакетами. Тип взаимодействия указывает на то, как обрабатываются пакеты и как они передаются от отправителя к получателю.

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

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

■ При передаче дейтаграмм не гарантируется доставка и правильный порядок пакетов. Пакеты могут теряться и приходить в произвольном порядке. Операционная система лишь обещает сделать "все возможное".

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

Пространство имен сокета определяет способ записи адресов. Например, в локальном пространстве имен адреса — это обычные имена файлов. В пространстве имен Internet адрес сокета состоит из IP-адреса компьютера, подключенного к сети, и номера порта. Благодаря номерам портов можно различать сокеты, созданные на одном компьютере.

Протокол определяет способ передачи данных. Основными семействами протоколов являются TCP/IP (ключевые сетевые протоколы, используемые в Internet) и AppleTalk (протоколы, используемые системами Macintosh). Сокеты могут также работать в соответствии с локальным коммуникационным протоколом UNIX. Не все комбинации типов взаимодействия, пространств имен и протоколов поддерживаются.

 

5.5.2. Системные вызовы

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

■ socket() — создает сокет;

■ close() — уничтожает сокет;

■ connect() — устанавливает соединение между двумя сокетами;

■ bind() — назначает серверному сокету адрес;

■ listen() — переводит сокет в режим приема запросов на подключение;

■ accept() — принимает запрос на подключение и создает новый сокет, который будет обслуживать данное соединение.

Сокеты представляются в программе файловыми дескрипторами.

Создание и уничтожение сокетов

Функции socket() и close() создают и уничтожают сокет соответственно. В первом случае необходимо задать три параметра: пространство имен, тип взаимодействия и протокол. Константы, определяющие пространство имен, начинаются с префикса PF_ (сокращение от "protocol family" — семейство протоколов). Например, константы PF_LOCAL и PF_UNIX соответствуют локальному пространству имен, а константа PF_INET — пространству имен Internet. Константы, определяющие тип взаимодействия, начинаются с префикса SOCK_. Сокетам, ориентированным на соединения, соответствует константа SOCK_STREAM, а дейтаграммным сокетам — константа SOCK_DGRAM.

Выбор протокола определяется связкой "пространство имен — тип взаимодействия". Поскольку для каждой такой пары, как правило, лучше всего подходит какой-то один протокол, в третьем параметре функции socket() обычно задается значение 0 (выбор по умолчанию). В случае успешного завершения функция socket() возвращает дескриптор сокета. Чтение и запись данных через сокеты осуществляется с помощью обычных файловых функций, таких как read(), write() и т.д. По окончании работы с сокетом его необходимо удалить с помощью функции close().

Вызов функции connect()

Чтобы установить соединение между двумя сокетами, следует на стороне клиента вызвать функцию connect(), указав адрес серверного сокета. Клиент — это процесс, инициирующий соединение, а сервер — это процесс, ожидающий поступления запросов на подключение. В первом параметре функции connect() задается дескриптор клиентского сокета, во втором— адрес серверного сокета, в третьем — длина (в байтах) адресной структуры, на которую ссылается второй параметр. Формат адреса будет разным в зависимости от пространства имен.

Передача данных

При работе с сокетами можно применять те же самые функции, что и при работе с файлами. О низкоуровневых функциях ввода-вывода, поддерживаемых в Linux, рассказывается в приложении Б, "Низкоуровневый ввод-вывод". Имеется также специальная функция send(), являющаяся альтернативой традиционной функции write().

 

5.5.3. Серверы

Жизненный цикл сервера можно представить так:

1) создание сокета, ориентированного на соединения (функция socket());

2) назначение сокету адреса привязки (функция bind());

3) перевод сокета в режим ожидания запросов (функция listen());

4) прием поступающих запросов (функция accept());

5) закрытие сокета (функция close()).

Данные не записываются и не читаются напрямую через серверный сокет. Вместо этого всякий раз, когда сервер принимает запрос на соединение, ОС Linux создает отдельный сокет, используемый для передачи данных через это соединение.

Серверному сокету необходимо с помощью функции bind() назначить адрес, чтобы клиент смог его найти. Первым аргументом функции является дескриптор сокета. Второй аргумент — это указатель на адресную структуру, формат которой будет зависеть от выбранного семейства адресов. Третий аргумент — это длина адресной структуры в байтах. После получения адреса сокет, ориентированный на соединения, должен вызвать функцию listen(), тем самым обозначив себя как сервер. Первым аргументом этой функции также является дескриптор сокета. Второй аргумент определяет, сколько запросов может находиться в очереди ожидания. Если очередь заполнена, все последующие запросы отвергаются. Этот аргумент задает не предельное число запросов, которое способен обработать сервер. а максимальное количество клиентов, которые могут находиться в режиме ожидания.

Сервер принимает от клиента запрос на подключение, вызывая функцию accept(). Первый ее аргумент — это дескриптор сокета. Второй аргумент указывает на адресную структуру, заполняемую адресом клиентского сокета. Третий аргумент содержит длину (в байтах) адресной структуры. Функция accept() создает новый сокет для обслуживания клиентского соединения и возвращает его дескриптор. Исходный серверный сокет продолжает принимать запросы от клиентов. Чтобы прочитать данные из сокета, не удалив их из входящей очереди, воспользуйтесь функцией recv(). Она принимает те же аргументы, что и функция read(), плюс дополнительный аргумент FLAGS. Флаг MSG_PEEK задает режим "неразрушающего" чтения, при котором прочитанные данные остаются в очереди.

 

5.5.4. Локальные сокеты

Сокеты, соединяющие процессы в пределах одного компьютера, работают в локальном пространстве имен (PF_LOCAL или PF_UNIX, это синонимы). Такие сокеты называются локальными или UNIX-сокетами. Их адресами являются имена файлов, указываемые только при создании соединения.

Имя сокета задается в структуре типа sockaddr_un. В поле sun_family необходимо записать константу AF_LOCAL, указывающую на то, что адрес находится в локальном пространстве имен. Поле sun_path содержит путевое имя файла и не может превышать 108 байтов. Длина структуры sockaddr_un вычисляется с помощью макроса SUN_LEN(). Допускается любое имя файла, но процесс должен иметь право записи в каталог, где находится файл. При подключении к сокету процесс должен иметь право чтения файла. Несмотря на то что файловая система может экспортироваться через NFS на разные компьютеры, только процессам, работающим в пределах одного компьютера, разрешается взаимодействовать друг с другом посредством локальных сокетов.

При работе в локальном пространстве имен допускается только протокол с номером 0.

Локальный сокет является частью файловой системы, поэтому он отображается командой ls (обратите внимание на букву s в строке режима):

% ls -l /tmp/socket

srwxrwx--x 1 user group 0 Nov 13 19:16 /tmp/socket

Если локальный сокет больше не нужен, его файл можно удалить с помощью функции unlink().

 

5.5.5. Примеры программ, работающих с локальными сокетами

Работу с локальными сокетами мы проиллюстрируем двумя программами. Первая (листинг 5.10) — это сервер. Он создает локальный сокет и переходит в режим ожидания запросов на подключение. Приняв запрос, сервер читает сообщения из сокета и отображает на на экране, пока соединение не будет закрыто. Если поступает сообщение "quit", сервер удаляет сокет и завершает свою работу. Программа socket-server ожидает путевое имя сокета в командной строке.

Листинг 5.10. ( socket-server.c ) Сервер локального сокета

#include

#include

#include

#include

#include

#include

/* Чтение сообщений из сокета и вывод их на экран. Функция

   продолжает работу до тех пор, пока сокет не будет закрыт.

   Функция возвращает 0, если клиент послал сообщение "quit",

   в противном случае возвращается ненулевое значение. */

int server(int client_socket) {

 while (1) {

  int length;

  char* text;

  /* Сначала читаем строку, в которой записана длина сообщения.

     Если возвращается 0, клиент закрыл соединение. */

  if (read(client_socket, &length, sizeof(length)) == 0)

   return 0;

  /* Выделение буфера для хранения текста. */

  text = (char*)malloc(length);

  /* Чтение самого сообщения и вывод его на экран. */

  read(client_socket, text, length);

  printf("%s\n", text);

  /* Очистка буфера. */

  free(text);

  /* Если клиент послал сообщение "quit.", работа сервера

     завершается. */

  if (!strcmp(text, "quit"))

   return 1;

 }

}

int main(int argc, char* const argv[]) {

 const char* const socket_name = argv[1];

 int socket_fd;

 struct sockaddr_un name;

 int client_sent_quit_message;

 /* Создание локального сокета. */

 socket_fd = socket(PF_LOCAL, SOCK_STREAM, 0);

 /* Переход в режим сервера. */

 name.sun_family = AF_LOCAL;

 strcpy(name.sun_path, socket_name);

 bind(socket_fd, SUN_LEN(&name));

 /* Ожидание запросов. */

 listen(socket_fd, 5);

 /* Непрерывный прием запросов на подключение. Для каждого

    клиента вызывается функция server(). Цикл продолжается,

    пока не будет получено сообщение "quit". */

 do {

  struct sockaddr_un client_name;

  socklen_t client_name_len;

  int client_socket_fd;

  /* Прием запроса. */

  client_socket_fd =

   accept(socket_fd, &client_name, &client_name_len);

  /* Обработка запроса. */

  client_sent_quit_message = server(client_socket_fd);

  /* Закрытие серверной стороны соединения. */

  close(client_socket_fd);

 } while(!client_sent_quit_message);

 /* Удаление файла локального сокета. */

 close(socket_fd);

 unlink(socket_name);

 return 0;

}

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

Листинг 5.11. ( socket-client.c ) Клиент локального сокета

#include

#include

#include

#include

#include

/* Запись строки TEXT в сокет, заданный

   дескриптором SOCKET_FD. */

void write_text(int socket_fd, const char* text) {

 /* Сначала указывается число байтов в строке, включая

    завершающий символ NULL. */

 int length = strlen(text) + 1;

 write(socket_fd, &length, sizeof(length));

 /* Запись строки. */

 write(socket_fd, text, length);

}

int main(int argc, char* const argv[]) {

 const char* const socket_name = argv[1];

 const char* const message = argv[2];

 int socket_fd;

 struct sockaddr_un name;

 /* Создание сокета. */

 socket_fd = socket(PF_LOCAL, SOCK_STREAM. 0);

 /* Сохранение имени сервера в адресной структуре. */

 name.sun_family = AF_LOCAL;

 strcpy(name.sun_path, socket_name);

 /* Подключение к серверному сокету. */

 connect(socket_fd, &name, SUN_LEN(&name));

 /* передача сообщения, заданного в командной строке. */

 write_text(socket_fd, message);

 close(socket_fd);

 return 0;

}

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

Чтобы проверить этот пример, запустите в одном терминальном окне серверную программу, указав путь к сокету, например:

% ./socket-server /tmp/socket

В другом окне запустите несколько раз клиентскую программу, задав тот же путь к сокету плюс требуемое сообщение:

% ./socket-client /tmp/socket "Hello, world."

% ./socket-client /tmp/socket "This is a test."

Сервер получит и отобразит эти сообщения. Чтобы закрыть сервер, пошлите ему сообщение "quit":

% ./socket-client /tmp/socket "quit"

 

5.5.6. Internet-сокеты

UNIX-сокеты используются для организации взаимодействия двух процессов, выполняющихся на одном компьютере. С другой стороны. Internet-сокеты позволяют соединять между собой процессы, работающие на разных компьютерах.

Пространству имен Internet соответствует константа PF_INET. Internet-сокеты чаще всего работают по протоколам TCP/IP. Протокол IP (Internet Protocol) отвечает за низкоуровневую доставку сообщений, осуществляя при необходимости их разбивку на пакеты и последующую компоновку. Доставка пакетов не гарантируется, поэтому они могут исчезать или приходить в неправильном порядке. Каждый компьютер в сети имеет свой IP-адрес. Протокол TCP (Transmission Control Protocol) функционирует поверх протокола IP и обеспечивает надежную доставку сообщений, ориентированную на установление соединений.

DNS-имена

Легче запоминать имена а не числа, поэтому служба DNS (Domain Name Service) закрепляет за IP-адресами доменные имена вида www.codesourcery.com . Служба DNS организована в виде всемирной иерархии серверов имен. Чтобы использовать доменные имена в программах, нет необходимости разбираться в протоколах DNS

Адрес Internet-сокета состоит из двух частей: адреса компьютера и номера порта. Эта информация хранится в структуре типа sockaddr_in. В поле sin_family необходимо записать константу AF_INET, указывающую на то, что адрес принадлежит пространству имен Internet. В поле sin_addr хранится IP-адрес компьютера в виде 32-разрядного целого числа. Благодаря номерам портов можно различать сокеты, создаваемые на одном компьютере. В разных системах многобайтовые значения могут храниться с разным порядком следования байтов, поэтому с помощью функции htons() необходимо преобразовать номер порта в число с сетевым порядком следования байтов.

Функция gethostbyname() преобразует адрес компьютера из текстового представления — стандартного точечного (например, 10.10.10.1) или доменного (например, www.codesourcery.com) — во внутреннее 32-разрядное. Функция возвращает указатель на структуру типа hostent. IP-адрес находится в ее поле h_addr.

Программа, представленная в листинге 5.12, иллюстрирует работу с Internet-сокетами. Программа запрашивает начальную страницу у Web-сервера, адрес которого указан в командной строке.

Листинг 5.12. ( socket-inet.c ) Чтение страницы с Web-сервера

#include

#include

#include

#include

#include

#include

#include

/* Отображение содержимого Web-страницы, полученной из

   серверного сокета. */

void get_home_page(int socket_fd) {

 char buffer[10000];

 ssize_t number_characters_read;

 /* Отправка HTTP-команды GET с запросом начальной страницы. */

 sprintf(buffer, "GET /\n");

 write(socket_fd, buffer, strlen(buffer));

 /* Чтение данных из сокета. Функция read() может вернуть

    не все данные сразу, поэтому продолжаем чтение, пока

    не будут получены все данные. */

 while (1) {

  number_characters_read = read(socket_fd, buffer, 10000);

  if (number_characters_read == 0)

   return;

  /* Запись данных в стандартный выходной поток. */

  fwrite(buffer, sizeof(char), number_characters_read, stdout);

 }

}

int main(int argc, char* const argv[]) {

 int socket_fd;

 struct sockaddr_in name;

 struct hostent* hostinfo;

 /* Создание сокета. */

 socket_fd = socket(PF_INET, SOCK_STREAM, 0);

 /* Запись имени сервера в адресную структуру. */

 name.sin_family = AF_INET;

 /* Преобразование адреса из текстового представления во

    внутреннюю форму. */

 hostinfo = gethostbyname(argv[1]);

 if (hostinfo == NULL)

  return 1;

 else

  name sin_addr = *((struct in_addr*)hostinfo->h_addr);

 /* Web-серверы используют порт 80. */

 name.sin_port = htons(80);

 /* Подключаемся к Web-серверу. */

 if (connect(socket_fd, &name,

  sizeof(struct sockaddr_in)) == -1) {

  perror("connect");

  return 1;

 }

 /* получаем содержимое начальной страницы сервера. */

 get_home_page(socket_fd);

 return 0;

}

Программа извлекает имя Web-сервера из командной строки (имя не является URL-адресом, т.е. в нем отсутствует префикс http://). Далее вызывается функция gethostbyname(), которая преобразует имя сервера в числовое представление. После этого программа подключает потоковый (TCP) сокет к порту 80 сервера. Web-серверы общаются по протоколу HTTP (Hypertext Transfer Protocol), поэтому программа посылает HTTP-команду GET, в ответ на которую сервер возвращает текст начальной страницы.

Стандартные номера портов

По существующему соглашению Web-серверы ожидают поступления запросов на порт 80. За большинством lntemet-сервисов закреплены стандартные номера портов. Например, защищенные Web-серверы работающие по протоколу SSL. прослушивают порт 443 а почтовые серверы (протокол SMTP) прослушивают порт 25

В Linux связи между именами протоколов/сервисов и номерами портов устанавливаются в файле /etc/services . В первой колонке файла указано имя протокола или сервисе. Во второй колонке приведен номер порта и тип взаимодействия: tcp — для сервисов ориентированных на соединения, и udp — для дейтаграмм.

При реализации собственных сетевых сервисов используйте номере портов, большие чем 1024

Например, чтобы получить начальную страницу с сервера www.codesourcery.com, введите следующую команду:

% ./socket-inet www.codesourcery.com

 

  content="text/html; charset=iso-8859-1">

...

 

5.5.7. Пары сокетов

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

Первые три параметра функции socketpair() такие же, как и в функции socket(): пространство имен (должно быть PF_LOCAL), тип взаимодействия и протокол. Последний параметр — это массив из двух целых чисел, куда будут записаны дескрипторы сокетов, подобно функции pipe().