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

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

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

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

Чтобы запустить редактор Emacs, наберите

emacs

.с

.h

.cpp

.hpp

.С

.H

C-x C-f

C-x

C-x C-s

C-x C-c

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

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

int main() {

printf("Hello, world\n");

}

Нажатие клавиши в строке вызова функции

printf()

int main() {

 printf("Hello, world\n");

}

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

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

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

Чтобы включить режим цветовых выделений, откройте файл

~/.emacs

(global-font-lock-mode t)

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

Внимательные читатели, возможно, обратили внимание на то, что строка, вставленная в файл

.emacs

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

Предположим, имеется проект, в который входят два исходных файла: один написан на С (

main.c

reciprocal.cpp

reciprocal

#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;

}

#include 

#include "reciprocal.hpp"

double reciprocal (int i) {

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

 assert(i != 0);

 return 1.0/i;

}

Есть также файл заголовков, который называется

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

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

g++

gcc

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

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

reciprocal

% ./reciprocal 7

The reciprocal of 7 is 0.142857

Как видите, компилятор

g++

printf()

-l

lib

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

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

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

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

-g

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()

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

M-x gdb

В каждый дистрибутив 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

gcc

gcc

libc

gdb

emacs

info

% info libs

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

/usr/include/bits/signum.h

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

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

Исходный код ядра Linux обычно хранится в каталоге

/usr/src/linux

Те, кто изучали языки С и C++, знают, что специальная функция main() является главной точкой входа в программу. Когда операционная система запускает программу на выполнение, она автоматически предоставляет определенные средства, позволяющие программе взаимодействовать как с самой системой, так и с пользователем. Читатели наверняка знают о том, что у функции

main()

argc

argv

stdout

stdin

cout

cin

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

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

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

ls

% ls -s /

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

ls

-s

/

Функция

main()

argc

argv

argc

argv

argc

Работа с аргументами командной строки сводится к просмотру параметров

argc

argv

Использование параметров

argc

argv

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 /

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

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()

■ Обычно функция

getopt_long()

switch

■ Если опция

getopt_long()

?

■ При обработке опции, имеющей аргумент, в глобальную переменную

optarg

■ Когда функция

getopt_long()

optind

argv

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

getopt_long()

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()

Есть также стандартный поток ошибок:

stderr

stdout

stderr

fprintf()

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

Все три стандартных потока доступны низкоуровневым функциям ввода-вывода (

read()

write()

stdin

stdout

stderr

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

bash

% program > output_file.txt 2>&1

% program 2>&1 | filter

Запись

2>&1

stderr

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()

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

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

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

■

USER

■

HOME

■

PATH

■

DISPLAY

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

printenv

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

$переменная

% echo $USER

samuel

% echo $HOME

/home/samuel

■ С помощью команды

export

EDITOR

% EDITOR=emacs

% export EDITOR

Или короче:

% export EDITOR=emacs

В программе доступ к переменным среды осуществляет функция

getenv()

NULL

setenv()

unsetenv()

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

environ

char**

NULL

ПЕРЕМЕННАЯ=значение

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

environ

#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

#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()

write()

Временные файлы, создаваемые функцией

mkstemp()

/tmp

unlink()

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

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()

fclose()

В Linux есть ряд других функций, предназначенных для генерирования временных файлов или их имен, в частности

mktemp()

tmpnam()

tempnam()

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

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

2.2.1. Макрос assert()

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

Простейший способ выявления ненормальных ситуаций — стандартный макрос

assert()

assert()

Каждый вызов макроса

assert()

В программах, критических к требованиям производительности, проверки

assert()

NDEBUG

-DNDEBUG

assert()

В связи с тем что макрос

assert()

++

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

do_something()

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

В Linux имеется удобная функция

strerror()

Есть также функция

perror()

stderr

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

open()

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

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

#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()

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

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++

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

test.c

app.c

int f() {

 return 3;

}

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

-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

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

/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++

libstdc++

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

Библиотеки часто связаны одна с другой. Например, во многих Linux-системах есть библиотека

libtiff

libjpeg

libz

В листинге 2.9 показана небольшая программа, использующая функции библиотеки

libtiff

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()

dlsym()

extern "С" void my_function();

Тем самым компилятору C++ будет запрещено подменять имя функции. При отсутствии спецификатора

extern "С"

my_function

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

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

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

У всякого процесса имеется также родительский процесс (за исключением специального демона

init

init

Работая с идентификаторами процессов в программах, написанных на языках С и C++, следует объявлять соответствующие переменные как имеющие тип

pid_t

getpid()

getppid()

#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

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

% ps

  PID TTY    TIME CMD

21693 pts/8 00:00:00 bash

21694 pts/8 00:00:00 ps

В данном случае мы видим два процесса. Первый из них.

bash

ps

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

% ps -е -о pid,ppid,command

Опция

-е

-о 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

bash

xterm

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

Для уничтожения процесса предназначена команда

kill

Команда

kill

SIGTERM

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

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

Функция

system()

/bin/sh

ls -l /

system()

#include 

int main() {

 int return_value;

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

 return return_value;

}

Функция

system()

Поскольку функция

system()

/bin/sh

bash

system()

root

fork()

exec()

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

В DOS и Windows API имеется семейство функций

spawn()

fork()

exec()

fork()

exec()

Вызывая функцию

fork()

fork()

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

getpid()

fork()

В листинге 3.3 приведен пример ветвления программы с помощью функции

fork()

if

else

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()

■ Функции, в названии которых присутствует суффикс

'p'

execvp()

execlp()

PATH

■ Функции, в названии которых присутствует суффикс

'v'

execv()

execvp()

execve()

NULL

'l'

execl()

execlp()

execle()

■ Функции, в названии которых присутствует суффикс

'e'

execve()

execle()

"ПЕРЕМЕННАЯ=значение"

Поскольку функция

exec()

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

argc

argv

main()

exec()

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

fork()

exec()

Программа, показанная в листинге 3.4, отображает содержимое корневого каталога с помощью команды

ls

ls

-l

/

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

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

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

nice -n

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

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

renice

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

nice()

Только программа с привилегиями пользователя

root

nice

renice

nice()

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

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()

&&

||

main()

exit()

main()

int

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

Читатели, запускавшие программу

fork-exec

ls

ls

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

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, порождает дочерний процесс, который немедленно завершается, тогда как родительский процесс берет минутную паузу, после чего тоже заканчивает работу, так и не позаботившись об удалении потомка.

#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

zombie

wait()

ps

zombie

init

init

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

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

exec()

wait()

Один подход заключается в периодическом вызове функции

wait3()

wait4()

wait()

WNOHANG

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

SIGCHLD

Таким образом, нужно организовать удаление дочерних процессов в обработчике сигнала

SIGCHLD

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;

}

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

pthread_t

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

void*

Функция

pthread_create()

■ Указатель на переменную типа

pthread_t

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

NULL

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

void* (*)(void*)

■ Значение аргумента потока (тип

void*

Функция

pthread_create()

Программа, представленная в листинге 4.1, создает поток, который непрерывно записывает символы 'x' в стандартный поток ошибок. После вызова функции

pthread_create()

#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

#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

main()

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

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

main()

wait()

pthread_join()

void*

NULL

В листинге 4.3 приведена исправленная версия функции

main()

main()

main()

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

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

Если второй аргумент функции

pthread_join()

void*

int

void*

pthread_join()

Программа, представленная в листинге 4.4, в отдельном потоке вычисляет n-е простое число и возвращает его в программу. Тем временем функция

main()

compute_prime()

#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, создает отсоединенный поток, устанавливая соответствующим образом атрибуты потока.

#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()

Обычно поток завершается при выходе из потоковой функции или вследствие вызова функции

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()

#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. Когда необходимо отменять поток

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

В отличие от процессов, все потоки программы делят общее адресное пространство. Это означает, что если один поток модифицирует ячейку памяти (например, глобальную переменную), то это изменение отразится на всех остальных потоках. Таким образом, потоки могут работать с одними и теми же данными, не используя механизмы межзадачного взаимодействия (рассматриваются в главе 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()

#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()

close_thread_log()

4.3.1. Обработчики очистки

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

Обработчик очистки вызывается при завершении потока. Он принимает один аргумент типа

void*

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

Для регистрации обработчика следует вызвать функцию

pthread_cleanup_push()

pthread_cleanup_pop()

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

#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()

pthread_exit()

try/catch

ThreadExitException

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

ThreadExitException

pthread_exit()

#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.1. Состояние гонки

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

struct job

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

job_queue

NULL

#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

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()

pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;

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

pthread_mutex_lock()

pthread_mutex_lock()

Функция

pthread_mutex_unlock()

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

#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()

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.

#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()

sem_wait()

4.4.6. Сигнальные (условные) переменные

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

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

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

#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()

set_thread_flag()

thread_function()

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

■ В цикле необходимо захватить исключающий семафор и прочитать значение флага.

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

■ Если флаг не установлен, одновременно выполняются операции освобождения семафора и перехода в режим ожидания сигнала.

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

Сигнальная переменная имеет тип

pthread_cond_t

■ Функция

pthread_cond_init()

pthread_cond_t

■ Функция

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()

#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. Далее оба потока окажутся заблокированными, так как им будет закрыт доступ к семафорам друг друга.

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

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

pthread_create()

fork()

Сказанное иллюстрирует программа

thread-pid

getpid()

#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]

Обратите внимание на то, что программе

thread-pid

thread_function()

pthread_create()

4.5.1. Обработка сигналов

Предположим, что многопотоковая программа принимает сигнал. В каком потоке будет вызван обработчик сигнала? Это зависит от версии UNIX. В Linux поведение программы объясняется тем. что потоки на самом деле реализуются в виде процессов.

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

fork()

Тем не менее подобная особенность реализации библиотеки Pthreads в Linux не согласуется со стандартом POSIX. Нельзя полагаться на нее в программах, рассчитанных на то, чтобы быть переносимыми.

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

pthread_kill()

4.5.2. Системный вызов clone()

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

fork()

В Linux имеется функция

clone()

fork()

pthread_create()

clone()

fork()

pthread_create()

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

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

■

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, иллюстрирует методику совместного использования памяти.

#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;