UNIX: разработка сетевых приложений — страница 33 из 42

Альтернативное устройство клиента и сервера

30.1. Введение

При написании сервера под Unix мы можем выбирать из следующих вариантов управления процессом:

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

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

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

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

В этой главе мы рассмотрим два других способа модификации устройства параллельного сервера.

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

■Предварительное создание потоков (prethreading). При запуске сервера создается некоторое количество (пул) потоков, и для обработки каждого клиента используется поток из данного набора.

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

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

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

Мы запускали различные экземпляры клиента с каждым сервером, измеряя время, которое процессор тратит на обслуживание определенного количества клиентских запросов. Чтобы информация об этом не оказалась рассеянной по всей главе, мы свели все полученные результаты в табл. 30.1, на которую в этой главе будем неоднократно ссылаться. Следует отметить, что значения времени, указанные в этой таблице, соответствуют процессорному времени, затраченному только на управление процессом, так как из фактического значения времени процессора мы вычитаем время, которое тратит на выполнение того же задания последовательный сервер, не имеющий накладных расходов, связанных с управлением процессом. Иными словами, нулевой точкой отсчета в данной таблице для нас является время, затраченное последовательным сервером. Для большей наглядности мы включили в таблицу строку для последовательного сервера с нулевыми значениями времени. В этой главе термином время центрального процессора на управление процессом (process control CPU time) мы обозначаем разность между фактическим значением времени центрального процессора и временем, затраченным последовательным сервером, для каждой конкретной системы.

Таблица 30.1. Сравнительные значения времени, затраченного каждым из обсуждаемых в данной главе сервером

Описание сервера	Время центрального процессора на управление процессом
0	Последовательный (точка отсчета; затраты на управление процессом отсутствуют)	0,0
1	Параллельный сервер, один вызов функции fork для обработки одного клиента	20,90
2	Предварительное создание дочерних процессов, каждый из которых вызывает функцию accept	1,80
3	Предварительное создание дочерних процессов с блокировкой для защиты accept	2,07
4	Предварительное создание дочерних процессов с использованием взаимного исключения для защиты accept	1,75
5	Предварительное создание дочерних процессов, родительский процесс передает дочернему дескриптор сокета	2,58
6	Параллельный сервер, создание одного потока на каждый клиентский запрос	0,99
7	Предварительное создание потоков с использованием взаимного исключения для защиты accept	1,93
8	Предварительное создание потоков, главный поток вызывает accept	2,05

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

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

Таблица 30.2. Количество клиентов, обслуженных каждым из 15 дочерних процессов или потоков

№ процесса или потока	Предварительное создание процессов без защиты accept (строка 2)	Предварительное создание процессов с защитой accept (строка 3)	Предварительное создание процессов, передача дескриптора (строка 5)	Предварительное порождение потоков, защита accept (строка 7)
0	333	347	1006	333
1	340	328	950	323
2	335	332	720	333
3	335	335	583	328
4	332	338	485	329
5	331	340	457	322
6	333	335	385	324
7	333	343	250	360
8	332	324	105	341
9	331	315	32	348
10	334	326	14	358
11	333	340	9	331
12	334	330	4	321
13	332	331	1	329
14	332	336	0	320
5000	5000	5000	5000

30.2. Альтернативы для клиента TCP

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

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

2. Листинг 6.1 содержит следующую, модифицированную версию клиента. С помощью функции select клиент получает информацию о событиях в сети во время ожидания ввода пользователя. Однако проблема этой версии заключается в том, что программа не способна корректно работать в пакетном режиме. В листинге 6.2 эта проблема решается путем применения функции shutdown.

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

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

5. В листинге 26.1 используются два потока вместо двух процессов.

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

30.3. Тестовый клиент TCP

В листинге 30.1[1] показан клиент, который будет использоваться для тестирования всех вариаций нашего сервера.

Листинг 30.1. Код клиента TCP для проверки различных версий сервера

//server/client.с
 1 #include "unp.h"

 2 #define MAXN 16384 /* максимальное количество байтов, которые могут быть
                         запрошены клиентом от сервера */

 3 int
 4 main(int argc, char **argv)
 5 {
 6  int i, j, fd, nchildren, nloops, nbytes;
 7  pid_t pid;
 8  ssize_t n,
 9   char request[MAXLINE], reply[MAXN];

10  if (argc != 6)
11   err_quit("usage: client <#children> "
12    "<#loops/child><#bytes/request>");

13  nchildren = atoi(argv[3]);
14  nloops = atoi(argv[4]);
15  nbytes = atoi(argv[5]);
16  snprintf(request, sizeof(request), "%d\n", nbytes); /* в конце
                                            символ новой строки */

17  for (i = 0; i < nchildren; i++) {
18   if ((pid = Fork()) == 0) { /* дочерний процесс */
19    for (j = 0; j < nloops; j++) {
20     fd = Tcp_connect(argv[1], argv[2]);

21     Write(fd, request, strlen(request));

22     if ((n = Readn(fd, reply, nbytes)) != nbytes)
23      err_quit("server returned %d bytes", n);

24     Close(fd); /* состояние TIME_WAIT на стороне клиента,
                     а не сервера */
25    }
26    printf("child %d done\n", i);
27    exit(0);
28   }
29   /* родительский процесс снова вызывает функцию fork */
30  }

31  while (wait(NULL) > 0) /* теперь родитель ждет завершения всех
                              дочерних процессов */
32   ;
33  if (errno != ECHILD)
34   err_sys("wait error");

35  exit(0);
36 }

10-12 Каждый раз при запуске клиента мы задаем имя узла или IP-адрес сервера, порт сервера, количество дочерних процессов, порождаемых функцией fork (что позволяет нам инициировать несколько одновременных соединений с сервером), количество запросов, которое каждый дочерний процесс должен посылать серверу, и количество байтов, отправляемых сервером в ответ на каждый запрос.17-30 Родительский процесс вызывает функцию fork для порождения каждого дочернего процесса, и каждый дочерний процесс устанавливает указанное количество соединений с сервером. По каждому соединению дочерний процесс посылает запрос, задавая количество байтов, которое должен вернуть сервер, а затем дочерний процесс считывает это количество данных с сервера. Родительский процесс просто ждет завершения выполнения всех дочерних процессов. Обратите внимание, что клиент закрывает каждое соединение TCP, таким образом состояние TCP TIME_WAIT имеет место на стороне клиента, а не на стороне сервера. Это отличает наше клиент-серверное соединение от обычного соединения HTTP.

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

% client 192.168.1.20 8888 5 500 4000

Таким образом создается 2500 соединений TCP с сервером: по 500 соединений от каждого из 5 дочерних процессов. По каждому соединению от клиента к серверу посылается 5 байт ("4000\n"), а от сервера клиенту передается 4000 байт. Мы запускаем клиент на двух различных узлах, соединяясь с одним и тем же сервером, что дает в сумме 5000 соединений TCP, причем максимальное количество одновременных соединений с сервером в любой момент времени равно 10.

ПРИМЕЧАНИЕ

Для проверки различных веб-серверов существуют изощренные контрольные тесты. Один из них называется WebStone. Информация о нем находится в свободном доступе по адресу http://www.mindcraft.com/webstone. Для общего сравнения различных альтернативных устройств сервера, которые мы рассматриваем в этой главе, нам не нужны столь сложные тесты.

Теперь мы представим девять различных вариантов устройства сервера.

30.4. Последовательный сервер TCP

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

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

% client 192.168.1.20 8888 1 5000 4000

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

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

30.5. Параллельный сервер TCP: один дочерний процесс для каждого клиента

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

Проблема с параллельными серверами заключается в количестве времени, которое тратит центральный процессор на выполнение функции fork для порождения нового дочернего процесса для каждого клиента. Давным-давно, в конце 80-х годов XX века, когда наиболее загруженные серверы обрабатывали сотни или тысячи клиентов за день, это было приемлемо. Но расширение Сети изменило требования. Теперь загруженными считаются серверы, обрабатывающие миллионы соединений TCP в день. Сказанное относится лишь к одиночным узлам, но наиболее загруженные сайты используют несколько узлов, распределяя нагрузку между ними (в разделе 14.2 [112] рассказывается об общепринятом способе распределения этой нагрузки, называемом циклическим обслуживанием DNS — DNS round robin). В последующих разделах описаны различные способы, позволяющие избежать вызова функции fork для каждого клиентского запроса, но тем не менее параллельные серверы остаются широко распространенными.

В листинге 30.2 показана функция main для нашего параллельного сервера TCP.

Листинг 30.2. Функция main для параллельного сервера TCP

//server/serv01.c
 1 include "unp.h"

 2 int
 3 main(int argc, char **argv)
 4 {
 5  int listenfd, connfd;
 6  pid_t childpid;
 7  void sig_chld(int), sig_int(int), web_child(int);
 8  socklen_t clilen, addrlen;
 9  struct sockaddr *cliaddr;

10  if (argc == 2)
11   listenfd = Tcp_listen(NULL, argv[1], &addrlen);
12  else if (argc == 3)
13   listenfd = Tcp_listen(argv[1], argv[2], &addrlen);
14  else
15   err_quit("usage: serv01 [  ] ");
16  cliaddr = Malloc(addrlen);

17  Signal(SIGCHLD, sig_chld);
18  Signal(SIGINT, sig_int);
19  for (;;) {
20   clilen = addrlen;
21   if ((connfd = accept(listenfd, cliaddr, &clilen)) < 0) {
22    if (errno == EINTR)
23     continue; /* назад к for() */
24    else
25     err_sys("accept error");
26   }
27   if ((childpid = Fork()) == 0) { /* дочерний процесс */
28    Close(listenfd); /* закрываем прослушиваемый сокет */
29    web_child(connfd); /* обрабатываем запрос */
30    exit(0);
31   }
32   Close(connfd); /* родительский процесс закрывает
                       присоединенный сокет */
33  }
34 }

Эта функция аналогична функции, показанной в листинге 5.9: она вызывает функцию fork для каждого клиентского соединения и обрабатывает сигналы SIGCHLD, приходящие от закончивших свое выполнение дочерних процессов. Тем не менее мы сделали эту функцию не зависящей от протокола за счет вызова функции tcp_listen. Мы не показываем обработчик сигнала sig_chld: он совпадает с показанным в листинге 5.8, но только без функции printf.

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

Листинг 30.3. Обработчик сигнала SIGINT

//server/serv01.c
35 void
36 sig_int(int signo)
37 {
38  void pr_cpu_time(void);
39  pr_cpu_time();
40  exit(0);
41 }

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

Листинг 30.4. Функция pr_cpu_time: вывод полного времени центрального процессора

//server/pr_cpu_time.c
 1 #include "unp.h"
 2 #include 

 3 #ifndef HAVE_GETRUSAGE_PROTO
 4 int getrusage(int, struct rusage*);
 5 #endif

 6 void
 7 pr_cpu_time(void)
 8 {
 9  double user, sys;
10  struct rusage myusage, childusage;

11  if (getrusage(RUSAGE_SELF, &myusage) < 0)
12   err_sys("getrusage error");
13  if (getrusage(RUSAGE_CHILDREN, &childusage) < 0)
14   err_sys("getrusage error");

15  user = (double)myusage.ru_utime.tv_sec +
16   myusage.ru_utime.tv_usec / 1000000.0;
17  user += (double)childusage.ru_utime.tv_sec +
18   childusage.ru_utime.tv_usec / 1000000.0;
19  sys = (double)myusage.ru_stime.tv_sec +
20   myusage.ru_stime.tv_usec / 1000000.0;
21  sys += (double)childusage.ru_stime.tv_sec +
22   childusage.ru_stime.tv_usec / 1000000.0;

21  printf("\nuser time = %g, sys time = %g\n", user, sys);
22 }

Функция getrusage вызывается дважды: она позволяет получить данные об использовании ресурсов вызывающим процессом (RUSAGE_SELF) и всеми его дочерними процессами, которые завершили свое выполнение (RUSAGE_CHILDREN). Выводится время, затраченное центральным процессором на выполнение пользовательского процесса (общее пользовательское время, total user time), и время, которое центральный процессор затратил внутри ядра на выполнение задач, заданных вызывающим процессом (общее системное время, total system time).

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

Листинг 30.5. Функция web_child: обработка каждого клиентского запроса

//server/web_child.c
 1 #include "unp.h"

 2 #define MAXN 16384 /* максимальное количество байтов, которое клиент
может запросить */

 3 void
 4 web_child(int sockfd)
 5 {
 6  int ntowrite;
 7  ssize_t nread;
 8  char line[MAXLINE], result[MAXN];

 9  for (;;) {
10   if ((nread = Readline(sockfd, line, MAXLINE)) == 0)
11    return; /* соединение закрыто другим концом */

12   /* line задает, сколько байтов следует отправлять обратно */
13   ntowrite = atol(line);
14   if ((ntowrite <= 0) || (ntowrite > MAXN))
15    err_quit("client request for bytes", ntowrite);
16   Writen(sockfd, result, ntowrite);
17  }
18 }

Установив соединение с сервером, клиент записывает одну строку, задающую количество байтов, которое сервер должен вернуть. Это отчасти похоже на HTTP: клиент отправляет небольшой запрос, а сервер в ответ отправляет требуемую информацию (часто это файл HTML или изображение GIF). В случае HTTP сервер обычно закрывает соединение после отправки клиенту затребованных данных, хотя более новые версии используют постоянные соединения (persistent connection), оставляя соединения TCP открытыми для дополнительных клиентских запросов. В нашей функции web_child сервер допускает дополнительные запросы от клиента, но, как мы видели в листинге 24.1, клиент посылает серверу только по одному запросу на каждое соединение, а по получении ответа от сервера это соединение закрывается.

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

ПРИМЕЧАНИЕ

Один из способов устройства сервера, который мы не рассматриваем в этой главе, — это сервер, инициируемый демоном inetd (см. раздел 13.5). С точки зрения управления процессами такой сервер подразумевает использование функций fork и exec, так что затраты времени центрального процессора будут еще больше, чем показанные в строке 1 для параллельного сервера.

30.6. Сервер TCP с предварительным порождением процессов без блокировки для вызова accept

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

Рис. 30.1. Предварительное создание дочерних процессов сервером

Преимущество этой технологии заключается в том, что обслуживание нового клиента не требует вызова функции fork родительским процессом, тем самым стоимость этого обслуживания понижается. Недостатком же является необходимость угадать, сколько дочерних процессов нужно создать при запуске. Если в некоторый момент времени количество имеющихся дочерних процессов будет равно количеству обслуживаемых клиентов, то дополнительные клиентские запросы будут игнорироваться до того момента, когда освободится какой-либо дочерний процесс. Но, как сказано в разделе 4.5, клиентские запросы в такой ситуации игнорируются не полностью. Для каждого из этих дополнительных клиентов ядро выполнит трехэтапное рукопожатие (при этом общее количество соединений не может превышать значения аргумента backlog функции listen), и при вызове функции accept установленные соединения будут переданы серверу. При этом, однако, приложение-клиент может заметить некоторое ухудшение в скорости получения ответа, так как, хотя функция connect может быть выполнена сразу же, запрос может не поступать на обработку еще некоторое время.

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

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

Листинг 30.6. Функция main сервера с предварительным порождением дочерних процессов

//server/serv02.c
 1 #include "unp.h"

 2 static int nchildren;
 3 static pid_t *pids;

 4 int
 5 main(int argc, char **argv)
 6 {
 7  int listenfd, i;
 8  socklen_t addrlen;
 9  void sig_int(int);
10  pid_t child_make(int, int, int);

11  if (argc == 3)
12   listenfd = Tcp_listen(NULL, argv[1], &addrlen);
13  else if (argc == 4)
14   listenfd = Tcp_listen(argv[1], argv[2], &addrlen);
15  else
16   err_quit("usage: serv02 [  ] <#children>");
17  nchildren = atoi(argv[argc - 1]);
18  pids = Calloc(nchildren, sizeof(pid_t));

19  for (i = 0; i < nchildren; i++)
20   pids[i] = child_make(i, listenfd, addrlen); /* возвращение родительского процесса */
21  Signal (SIGINT, sig_int);

22  for (;;)
23   pause(); /* дочерние процессы завершились */
24 }

11-18 Дополнительный аргумент командной строки указывает, сколько требуется создать дочерних процессов. В памяти выделяется место для размещения массива, в который записываются идентификаторы дочерних процессов, используемые функцией main при окончании работы программы для завершения этих процессов.19-20 Каждый дочерний процесс создается функцией child_make, которую мы показываем в листинге 30.8.

Код обработчика сигнала SIGINT, представленный в листинге 30.7, отличается от кода, приведенного в листинге 30.3.

Листинг 30.7. Обработчик сигнала SIGINT

//server/serv02.c
25 void
26 sig_int(int signo)
27 {
28  int i;
29  void pr_cpu_time(void);

30  /* завершаем все дочерние процессы */
31  for (i = 0; i < nchildren; i++)
32   kill(pids[i], SIGTERM);
33  while (wait(NULL) > 0) /* ждем завершения всех дочерних процессов */
34   ;
35  if (errno != ECHILD)
36   err_sys("wait error");

37  pr_cpu_time();
38  exit(0);
39 }

30-34 Функция getrusage сообщает об использовании ресурсов всеми дочерними процессами, завершившими свое выполнение, поэтому мы должны завершить все дочерние процессы к моменту вызова функции pr_cpu_time. Для этого дочерним процессам посылается сигнал SIGTERM, после чего мы вызываем функцию wait и ждем завершения выполнения дочерних процессов.

В листинге 30.8 показана функция child_make, вызываемая из функции main для порождения очередного дочернего процесса.

Листинг 30.8. Функция child_make: создание очередного дочернего процесса

//server/child02.c
 1 #include "unp.h"

 2 pid_t
 3 child_make(int i, int listenfd, int addrlen)
 4 {
 5 pid_t pid;
 6 void child_main(int, int, int);

 7 if ( (pid = Fork()) > 0)
 8 return (pid); /* родительский процесс */

 9 child_main(i, listenfd, addrlen); /* никогда не завершается */
10 }

7-9 Функция fork создает очередной дочерний процесс и возвращает родителю идентификатор дочернего процесса. Дочерний процесс вызывает функцию child_main, показанную в листинге 30.9, которая представляет собой бесконечный цикл.

Листинг 30.9. Функция child_main: бесконечный цикл, выполняемый каждым дочерним процессом

//server/child02.c
11 void
12 child_main(int i, int listenfd, int addrlen)
13 {
14  int connfd;
15  void web_child(int);
16  socklen_t clilen;
17  struct sockaddr *cliaddr;

18  cliaddr = Malloc(addrlen);

19  printf("child %ld starting\n", (long)getpid());
20  for (;;) {
21   clilen = addrlen;
22   connfd = Accept(listenfd, cliaddr, &clilen);

23   web_child(connfd); /* обработка запроса */
24   Close(connfd);
25  }
26 }

20-25 Каждый дочерний процесс вызывает функцию accept, и когда она завершается, функция web_child (см. листинг 30.5) обрабатывает клиентский запрос. Дочерний процесс продолжает выполнение цикла, пока родительский процесс не завершит его.

Реализация 4.4BSD

Если вы никогда ранее не сталкивались с таким типом устройства сервера (несколько процессов, вызывающих функцию accept на одном и том же прослушиваемом сокете), вас, вероятно, удивляет, что это вообще может работать. Пожалуй, здесь уместен краткий экскурс, описывающий реализацию этого механизма в Беркли-ядрах (более подробную информацию вы найдете в [128]).

Родитель сначала создает прослушиваемый сокет, а затем — дочерние процессы. Напомним, что каждый раз при вызове функции fork происходит копирование всех дескрипторов в каждый дочерний процесс. На рис. 30.2 показана организация структур proc (по одной структуре на процесс), одна структура file для прослушиваемого дескриптора и одна структура socket.

Рис. 30.2. Организация структур proc, file и socket

Дескрипторы — это просто индексы массива, содержащегося в структуре proc, который ссылается на структуру file. Одна из целей дублирования дескрипторов в дочерних процессах, осуществляемого функцией fork, заключается в том, чтобы данный дескриптор в дочернем процессе ссылался на ту же структуру file, на которую этот дескриптор ссылается в родительском процессе. Каждая структура file содержит счетчик ссылок, который начинается с единицы, когда открывается первый файл или сокет, и увеличивается на единицу при каждом вызове функции fork и при каждом дублировании дескриптора (с помощью функции dup). В нашем примере с N дочерними процессами счетчик ссылок в структуре file будет содержать значение N+1 (учитывая родительский процесс, у которого по-прежнему открыт прослушиваемый дескриптор, хотя родительский процесс никогда не вызывает функцию accept).

При запуске программы создается N дочерних процессов, каждый из которых может вызывать функцию accept, и все они переводятся родительским процессом в состояние ожидания [128, с. 458]. Когда от клиента прибывает первый запрос на соединение, все N дочерних процессов «просыпаются», так как все они были переведены в состояние ожидания по одному и тому же «каналу ожидания» — полю so_timeo структуры socket, как совместно использующие один и тот же прослушиваемый дескриптор, указывающий на одну и ту же структуру socket. Хотя «проснулись» все N дочерних процессов, только один из них будет связан с клиентом. Остальные N - 1 снова перейдут в состояние ожидания, так как длина очереди клиентских запросов снова станет равна нулю, после того как первый из дочерних процессов займется обработкой поступившего запроса.

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

Эффект наличия слишком большого количества дочерних процессов

В табл. 30.1 (строка 2) указано время (1,8 с), затрачиваемое центральным процессором в случае наличия 15 дочерних процессов, обслуживающих не более 10 клиентов. Мы можем оценить эффект «общей побудки», увеличивая количество дочерних процессов и оставляя то же максимальное значение количества обслуживаемых клиентов (10). Мы не показываем результаты, получаемые при увеличении количества дочерних потоков, потому что они не настолько интересны. Поскольку любое количество дочерних потоков свыше 10 может считаться избыточным, проблема «общей побудки» усугубляется, а затрачиваемое на управление процессами время увеличивается.

ПРИМЕЧАНИЕ

Некоторые ядра Unix снабжены функцией, которая выводит из состояния ожидания только один процесс для обработки одного клиентского запроса [107]. Чаще всего она называется wakeup_one.

Распределение клиентских соединений между дочерними процессами

Следующей темой обсуждения является распределение клиентских соединений между свободными дочерними процессами, блокированными в вызове функции accept. Для получения этой информации мы модифицируем функцию main, размещая в совместно используемой области памяти массив счетчиков, которые представляют собой длинные целые числа (один счетчик на каждый дочерний процесс). Это делается следующим образом:

long *cptr, *meter(int); /* для подсчета количества клиентов на один
дочерний процесс */
cptr = meter(nchildren); /* перед порождением дочернего процесса */

В листинге 30.10 показана функция meter.

Листинг 30.10. Функция meter, которая размещает массив в совместно используемой памяти

//server/meter.c
 1 #include "unp.h"
 2 #include 

 3 /* Размещаем массив "nchildren" длинных целых чисел
 4  * в совместно используемой области памяти.
 5  * Эти числа используются как счетчики количества
    * клиентов, обслуженных данным дочерним процессом,
 6  * см. с. 467-470 книги [110]"
 7  */

 8 long*
 9 meter(int nchildren)
10 {
11  int fd;
12  long *ptr;

13 #ifdef MAP_ANON
14  ptr = Mmap(0, nchildren * sizeof(long), PROT_READ | PROT_WRITE,
15   MAP_ANON | MAP_SHARED, -1, 0);
16 #else
17  fd = Open("/dev/zero", O_RDWR, 0);

18  ptr = Mmap(0, nchildren * sizeof(long), PROT_READ | PROT_WRITE,
19   MAP_SHARED, fd, 0);
20  Close(fd);
21 #endif

22  return (ptr);
23 }

Мы используем неименованное отображение в память, если оно поддерживается (например, в 4.4BSD), или отображение файла /dev/zero (например, SVR4). Поскольку массив создается функцией mmap до того, как родительский процесс порождает дочерние, этот массив затем используется совместно родительским и всеми дочерними процессами, созданными функцией fork.

Затем мы модифицируем нашу функцию child_main (см. листинг 30.9) таким образом, чтобы каждый дочерний процесс увеличивал значение соответствующего счетчика на единицу при завершении функции accept, а после завершения выполнения всех дочерних процессов обработчик сигнала SIGINT выводил бы упомянутый массив счетчиков.

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

Коллизии при вызове функции select

Рассматривая данный пример в 4.4BSD, мы можем исследовать еще одну проблему, которая встречается довольно редко и поэтому часто остается непонятой до конца. В разделе 16.13 [128] говорится о коллизиях (collisions), возникающих при вызове функции select несколькими процессами на одном и том же дескрипторе, и о том, каким образом ядро решает эту проблему. Суть проблемы в том, что в структуре socket предусмотрено место только для одного идентификатора процесса, который выводится из состояния ожидания по готовности дескриптора. Если же имеется несколько процессов, ожидающих, когда будет готов данный дескриптор, то ядро должно вывести из состояния ожидания все процессы, блокированные в вызове функции select, так как ядро не знает, какие именно процессы ожидают готовности данного дескриптора.

Коллизии при вызове функции select в нашем примере можно форсировать, предваряя вызов функции accept из листинга 30.9 вызовом функции select в ожидании готовности к чтению на прослушиваемом сокете. Дочерние процессы будут теперь блокированы в вызове функции select, а не в вызове функции accept. В листинге 30.11 показана изменяемая часть функции child_main, при этом измененные по отношению к листингу 30.9 строки отмечены знаками +.

Листинг 30.11. Модификация листинга 30.9: блокирование в вызове select вместо блокирования в вызове accept

  printf("child %ld starting\n", (long)getpid());
+ FD_ZERO(&rset);
  for (;;) {
+  FD_SET(listenfd, &rset);
+  Select(listenfd+1, &rset, NULL, NULL, NULL);
+  if (FD_ISSET(listenfd, &rset) == 0)
+   err_quit("listenfd readable");
+
   clilen = addrlen;
   connfd = Accept(listenfd, cliaddr, &clilen);

   web_child(connfd); /* обработка запроса */
   Close(connfd);
  }

Если, проделав это изменение, мы проверим значение счетчика ядра BSD/OS nselcoll, мы увидим, что в первом случае при запуске сервера произошло 1814 коллизий, а во втором случае — 2045. Так как при каждом запуске сервера два клиента создают в сумме 5000 соединений, приведенные выше значения указывают, что примерно в 35-40% случаев вызовы функции select приводят к коллизиям.

Если сравнить значения времени, затраченного центральным процессором в этом примере, то получится, что при добавлении вызова функции select это значение увеличивается с 1,8 до 2,9 с. Частично это объясняется, вероятно, добавлением системного вызова (так как теперь мы вызываем не только accept, но еще и select), а частично — накладными расходами, связанными с коллизиями.

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

30.7. Сервер TCP с предварительным порождением процессов и защитой вызова accept блокировкой файла

Описанная выше реализация, позволяющая нескольким процессам вызывать функцию accept на одном и том же прослушиваемом дескрипторе, возможна только для систем 4.4BSD, в которых функция accept реализована внутри ядра. Ядра системы SVR4, в которых accept реализована как библиотечная функция, не допускают этого. В самом деле, если мы запустим сервер из предыдущего раздела, в котором имеется несколько дочерних процессов, в Solaris 2.5 (система SVR4), то вскоре после того, как клиенты начнут соединяться с сервером, вызов функции accept в одном из дочерних процессов вызовет ошибку EPROTO, что свидетельствует об ошибке протокола.

ПРИМЕЧАНИЕ

Причины возникновения этой проблемы с библиотечной версией функции accept в SVR4 связаны с реализацией потоков STREAMS и тем фактом, что библиотечная функция accept не является атомарной операцией. В Solaris 2.6 эта проблема решена, но в большинстве реализаций SVR4 она остается.

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

Существует несколько способов реализации защиты вызова функции accept, о которых рассказывается во втором томе[2] данной серии. В этом разделе мы используем блокировку файла функцией fcntl согласно стандарту POSIX.

Единственным изменением в функции main (см. листинг 30.6) будет добавление вызова функции my_lock_init перед началом цикла, в котором создаются дочерние процессы:

+ my_lock_init("/tmp/lock.XXXXXX"); /* один файл для всех дочерних
                                       процессов */
  for (i = 0; i < nchildren; i++)
   pids[i] = child_make(i, listenfd, addrlen); /* возвращение
                                       родительского процесса */

Функция child_make остается такой же, как в листинге 30.8. Единственным изменением функции child_main (см. листинг 30.9) является блокирование перед вызовом функции accept и снятие блокировки после завершения этой функции:

  for (;;) {
   clilen = addrlen;
+  my_lock_wait();
    connfd = Accept(listenfd, cliaddr, &clilen);
+   my_lock_release();

    web_child(connfd); /* обработка запроса */
    Close(connfd);
   }

В листинге 30.12 показана наша функция my_lock_init, в которой используется блокировка файла согласно стандарту POSIX.

Листинг 30.12. Функция my_lock_init: блокировка файла

//server/lock_fcntl.c
 1 #include "unp.h"

 2 static struct flock lock_it, unlock_it;
 3 static int lock_fd = -1;
 4 /* fcntl() не выполнится, если не будет вызвана функция my_lock_init() */

 5 void
 6 my_lock_init(char *pathname)
 7 {
 8  char lock_file[1024];

 9  /* копируем строку вызывающего процесса на случай, если это константа */
10  strncpy(lock_file, pathname, sizeof(lock_file));
11  lock_fd = Mkstemp(lock_file);

12  Unlink(lock_file); /* но lock_fd остается открытым */

13  lock_it.l_type = F_WRLCK;
14  lock_it.l_whence = SEEK_SET;
15  lock_it.l_start = 0;
16  lock_it.l_len = 0;

17  unlock_it.l_type = F_UNLCK;
18  unlock_it.l_whence = SEEK_SET;
19  unlock_it.l_start = 0;
20  unlock_it.l_len = 0;
21 }

9-12 Вызывающий процесс задает шаблон для имени файла в качестве аргумента функции my_lock_init, и функция mkstemp на основе этого шаблона создает уникальное имя файла. Затем создается файл с этим именем и сразу же вызывается функция unlink, в результате чего имя файла удаляется из каталога. Если в программе впоследствии произойдет сбой, то файл исчезнет безвозвратно. Но пока он остается открытым в одном или нескольких процессах (иными словами, пока счетчик ссылок для этого файла больше нуля), сам файл не будет удален. (Отметим, что между удалением имени файла из каталога и закрытием открытого файла существует фундаментальная разница.)13-20 Инициализируются две структуры flock: одна для блокирования файла, другая для снятия блокировки. Блокируемый диапазон начинается с нуля (l_whence =SEEK_SET, l_start=0). Значение l_len равно нулю, то есть блокирован весь файл. В этот файл ничего не записывается (его длина всегда равна нулю), но такой тип блокировки в любом случае будет правильно обрабатываться ядром.

ПРИМЕЧАНИЕ

Сначала автор инициализировал эти структуры при объявлении:

static struct flock lock_it = { F_WRLCK, 0, 0, 0, 0 };
static struct flock unlock_it = { F_UNLCK, 0, 0, 0, 0 };

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

Исключением из этого правила является ситуация, когда инициализатор структуры обеспечивается реализацией. Например, при инициализации взаимного исключения в POSIX в главе 26 мы писали:

pthread_mutex_t mlock = PTHREAD_MUTEX_INITIALIZER;

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

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

Листинг 30.13. Функции my_lock_wait (установление блокировки файла) и my_lock_release (снятие блокировки файла)

//server/lock_fcntl.c
23 void
24 my_lock_wait()
25 {
26  int rc;
27  while ((rc = fcntl(lock_ld, F_SETLKW, &lock_it)) < 0 {
28   if (errno == EINTR)
29    continue;
30   else
31    errsys("fcntl error for my_lock_wait");
32  }
33 }

34 void
35 my_lock_release()
36 {
37  if (fcntl(lock_fd, F_SETLKW, &unlock_it)) < 0)
38   errsys("fcntl error for my_lock_release");
39 }

Новая версия нашего сервера с предварительным порождением процессов работает теперь под SVR4, гарантируя, что в данный момент времени только один дочерний процесс блокирован в вызове функции accept. Сравнивая строки 2 и 3 в табл. 30.1 (результаты для серверов Digital Unix и BSD/OS), мы видим, что такой тип блокировки увеличивает время, затрачиваемое центральным процессором на узле сервера.

ПРИМЕЧАНИЕ

Веб-сервер Apache (http://www.apache.org) использует технологию предварительного порождения процессов, причем если позволяет реализация, все дочерние процессы блокируются в вызове функции accept, иначе используется блокировка файла для защиты вызова accept.

Эффект наличия слишком большого количества дочерних процессов

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

Распределение клиентских соединений между дочерними процессами

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

30.8. Сервер TCP с предварительным порождением процессов и защитой вызова accept при помощи взаимного исключения

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

Функция main остается такой же, как и в предыдущем разделе, то же относится к функциям child_make и child_main. Меняются только три функции, осуществляющие блокировку. Чтобы использовать взаимное исключение между различными процессами, во-первых, требуется хранить это взаимное исключение в разделяемой процессами области памяти, а во-вторых, библиотека потоков должна получить указание о том, что взаимное исключение совместно используется различными процессами.

ПРИМЕЧАНИЕ

Требуется также, чтобы библиотека потоков поддерживала атрибут PTHREAD_PROCESS_SHARED.

Существует несколько способов разделения памяти между различными процессами, что мы подробно описываем во втором томе[2] данной серии. В этом примере мы используем функцию mmap с устройством /dev/zero, которое работает с ядрами Solaris и другими ядрами SVR4. В листинге 30.14 показана только функция my_lock_init.

Листинг 30.14. Функция my_lock_init: использование взаимного исключения потоками, относящимися к различным процессам (технология Pthread)

//server/lock_pthread.c
 1 #include "unpthread.h"

 2 #include 
 3 static pthread_mutex_t *mptr; /* фактически взаимное исключение будет
                                    в совместно используемой памяти */

 4 void
 5 my_lock_init(char *pathname)
 6 {
 7  int fd;
 8  pthread_mutexattr_t mattr;

 9  fd = Open("/dev/zero", O_RDWR, 0);

10  mptr = Mmap(0, sizeof(pthread_mutex_t), PROT_READ | PROT_WRITE,
11   MAP_SHARED, fd, 0);
12  Close(fd);

13  Pthread_mutexattr_init(&mattr);
14  Pthread_mutexattr_setpshared(&mattr, PTHREAD_PROCESS_SHARED);
15  Pthread_mutex_init(mptr, &mattr);
16 }

9-12 Мы открываем (open) файл /dev/zero, а затем вызываем mmap. Количество байтов (второй аргумент этой функции) — это размер переменной pthread_mutex_t. Затем дескриптор закрывается, но для нас это не имеет значения, так как файл уже отображен в память.13-15 В приведенных ранее примерах взаимных исключений Pthread мы инициализировали глобальные статические взаимные исключения, используя константу PTHREAD_MUTEX_INITIALIZER (см., например, листинг 26.12). Но располагая взаимное исключение в совместно используемой памяти, мы должны вызвать некоторые библиотечные функции Pthreads, чтобы сообщить библиотеке о наличии семафора в совместно используемой памяти и о том, что он будет применяться для синхронизации потоков, относящихся к различным процессам. Мы должны инициализировать структуру pthread_mutexattr_t задаваемыми по умолчанию атрибутами взаимного исключения, а затем установить значение атрибута PTHREAD_PROCESS_SHARED. (По умолчанию значением этого атрибута должно быть PTHREAD_PROCESS_PRIVATE, что подразумевает использование взаимного исключения только в пределах одного процесса.) Затем вызов pthread_mutex_init инициализирует взаимное исключение указанными атрибутами.

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

Листинг 30.15. Функции my_lock_wait и my_lock_release: использование блокировок Pthread

//server/lock_pthread.c
17 void
18 my_lock_wait()
19 {
20  Pthread_mutex_lock(mptr),
21 }

22 void
23 my_lock_release()
24 {
25  Pthread_mutex_unlock(mptr);
26 }

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

30.9. Сервер TCP с предварительным порождением процессов: передача дескриптора

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

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

В данном примере для каждого дочернего процесса нам нужна некая структура, содержащая информацию о нем. Заголовочный файл child.h, в котором определяется структура Child, показан в листинге 30.16.

Листинг 30.16. Структура Child

//server/child.h
1 typedef struct {
2  pid_t child_pid;  /* ID процесса */
3  int child_pipefd; /* программный (неименованный) канал между
                        родительским и дочерним процессами */
4  int child_status; /* 0 = готово */
5  long child_count; /* количество обрабатываемых соединений */
6 } Child;

7 Child *cptr; /* массив структур Child */

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

Рассмотрим сначала функцию child_make, которая приведена в листинге 30.17. Мы создаем канал и доменный сокет Unix (см. главу 14) перед вызовом функции fork. После того, как создан дочерний процесс, родительский процесс закрывает один дескриптор (sockfd[1]), а дочерний процесс закрывает другой дескриптор (sockfd[0]). Более того, дочерний процесс подключает свой дескриптор канала (sockfd[1]) к стандартному потоку сообщений об ошибках, так что каждый дочерний процесс просто использует это устройство для связи с родительским процессом. Этот механизм проиллюстрирован схемой, приведенной на рис. 30.3.

Листинг 30.17. Функция child_make: передача дескриптора в сервере с предварительным порождением дочерних процессов

//server/child05.c
 1 #include "unp.h"
 2 #include "child.h"

 3 pid_t
 4 child_make(int i, int listenfd, int addrlen)
 5 {
 6  int sockfd[2];
 7  pid_t pid;
 8  void child_main(int, int, int);

 9  Socketpair(AF_LOCAL, SOCK_STREAM, 0, sockfd);

10  if ((pid = Fork()) > 0) {
11   Close(sockfd[1]);
12   cptr[i].child_pid = pid;
13   cptr[i].child_pipefd = sockfd[0];
14   cptr[i].child_status = 0;
15   return (pid); /* родительский процесс */
16  }
17  Dup2(sockfd[1], STDERR_FILENO); /* канал от дочернего процесса к
                                       родительскому */
18  Close(sockfd[0]);
19  Close(sockfd[1]);
20  Close(listenfd); /* дочернему процессу не требуется, чтобы
                        он был открыт */
21  child_main(i, listenfd, addrlen); /* никогда не завершается */
22 }

Рис. 30.3. Канал после того, как дочерний и родительский процесс закрыли один конец

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

Рис. 30.4. Каналы после создания всех дочерних процессов

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

Листинг 30.18. Функция main, использующая передачу дескриптора

//server/serv05.c
 1 #include "unp.h"
 2 #include "child.h"

 3 static int nchildren;

 4 int
 5 main(int argc, char **argv)
 6 {
 7  int listenfd, i, navail, maxfd, nsel, connfd, rc;
 8  void sig_int(int);
 9  pid_t child_make(int, int, int);
10  ssize_t n;
11  fd_set rset, masterset;
12  socklen_t addrlen, clilen;
13  struct sockaddr *cliaddr;

14  if (argc == 3)
15   listenfd = Tcp_listen(NULL, argv[1], &addrlen);
16  else if (argc == 4)
17   listenfd = Tcp_listen(argv[1], argv[2], &addrlen);
18  else
19   err_quit("usage; serv05 [  ] <#children>");

20  FD_ZERO(&masterset);
21  FD_SET(listenfd, &masterset);
22  maxfd = listenfd;
23  cliaddr = Malloc(addrlen);

24  nchildren = atoi(argv[argc - 1]);
25  navail = nchildren;
26  cptr = Calloc(nchildren, sizeof(Child));

27  /* предварительное создание дочерних процессов */
28  for (i = 0; i < nchildren; i++) {
29   child_make(i, listenfd, addrlen); /* родительский процесс
                                          завершается */
30   FD_SET(cptr[i].child_pipefd, &masterset);
31   maxfd = max(maxfd, cptr[i].child_pipefd);
32  }

33  Signal(SIGINT, sig_int);

34  for (;;) {
35   rset = masterset;
36   if (navail <= 0)
37    FD_CLR(listenfd, &rset); /* выключаем, если нет свободных
                                  дочерних процессов */
38   nsel = Select(maxfd + 1, &rset, NULL, NULL, NULL);

39   /* проверка новых соединений */
40   if (FD_ISSET(listenfd, &rset)) {
41    clilen = addrlen;
42    connfd = Accept(listenfd, cliaddr, &clilen);

43    for (i = 0; i < nchildren; i++)
44     if (cptr[i].child_status == 0)
45      break; /* свободный */

46    if (i == nchildren)
47     err_quit("no available children");
48    cptr[i].child_status = 1; /* отмечаем этот дочерний процесс как
                                   занятый */
49    cptr[i].child_count++;
50    navail--;

51    n = Write_fd(cptr[i].child_pipefd, 1, connfd);
52    Close(connfd);
53    if (--nsel == 0)
54     continue; /* с результатами select() закончено */
55   }
56   /* поиск освободившихся дочерних процессов */
57   for (i = 0; i < nchildren; i++) {
58    if (FD_ISSET(cptr[i].child_pipefd, &rset)) {
59     if ((n = Read(cptr[i].child_pipefd, &rc, 1)) == 0)
60      err_quit("child %d terminated unexpectedly", i);
61     cptr[i].child_status = 0;
62     navail++;
63     if (--nsel == 0)
64      break; /* с результатами select() закончено */
65    }
66   }
67  }
68 }

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

36-37 Счетчик navail отслеживает количество свободных дочерних процессов. Если его значение становится равным нулю, прослушиваемый сокет в наборе дескрипторов функции select выключается. Это предотвращает прием нового соединения в тот момент, когда нет ни одного свободного дочернего процесса. Ядро по- прежнему устанавливает эти соединения в очередь, пока их количество не превысит значения аргумента backlog функции listen, заданного для прослушиваемого сокета, но мы не хотим их принимать, пока у нас не появится свободный дочерний процесс, готовый обрабатывать клиентский запрос.

Прием нового соединения

39-55 Если прослушиваемый сокет готов для считывания, можно принимать (accept) новое соединение. Мы находим первый свободный дочерний процесс и передаем ему присоединенный сокет с помощью функции write_fd, приведенной в листинге 15.11. Вместе с дескриптором мы передаем 1 байт, но получатель не интересуется содержимым этого байта. Родитель закрывает присоединенный сокет.

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

Обработка вновь освободившихся дочерних процессов

56-66 Когда дочерний процесс заканчивает обработку клиентского запроса, наша функция child_main записывает один байт в канал для родительского процесса. Тем самым родительский конец канала становится доступным для чтения. Упомянутый байт считывается (но его значение при этом игнорируется), а дочерний процесс помечается как свободный. Если же дочерний процесс завершит свое выполнение неожиданно, его конец канала будет закрыт, а операция чтения (read) возвратит нулевое значение. Это значение перехватывается и дочерний процесс завершается, но более удачным решением было бы записать ошибку и создать новый дочерний процесс для замены завершенного.

Функция child_main показана в листинге 30.19.

Листинг 30.19. Функция child_main: передача дескриптора в сервере с предварительным порождением дочерних процессов

//server/child05.c
23 void
24 child_main(int i, int listenfd, int addrlen)
25 {
26  char c;
27  int connfd;
28  ssize_t n;
29  void web_child(int);

30  printf("child %ld starting\n", (long)getpid());
31  for (;;) {
32   if ((n = Read_fd(STDERR_FILENO, &c, 1, &connfd)) == 0)
33    err_quit("read_fd returned 0");
34   if (connfd < 0)
35    err_quit("no descriptor from read_fd");

36   web_child(connfd); /* обработка запроса */
37   Close(connfd);

38   Write(STDERR_FILENO, "", 1); /* сообщаем родительскому процессу
                                     о том, что дочерний освободился */
39  }
40 }

Ожидание дескриптора от родительского процесса

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

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

38 Закончив обработку очередного клиентского запроса, мы записываем (write) 1 байт в канал, чтобы сообщить, что данный дочерний процесс освободился.

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

В табл. 30.2 показаны значения счетчиков child_count из структуры Child, которые выводятся обработчиком сигнала SIGINT по завершении работы сервера. Дочерние процессы, расположенные ближе к началу массива, обрабатывают большее количество клиентских запросов, как было указано при обсуждении листинга 30.18.

30.10. Параллельный сервер TCP: один поток для каждого клиента

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

Наша первая версия сервера с использованием потоков показана в листинге 30.20. Это модификация листинга 30.2: в ней создается один поток для каждого клиента вместо одного дочернего процесса для каждого клиента. Эта версия во многом похожа на сервер, представленный в листинге 26.2.

Листинг 30.20. Функция main для сервера TCP, использующего потоки

//server/serv06.c
 1 #include "unpthread.h"

 2 int
 3 main(int argc, char **argv)
 4 {
 5  int listenfd, connfd;
 6  void sig_int(int);
 7  void *doit(void*);
 8  pthread_t tid;
 9  socklen_t clilen, addrlen;
10  struct sockaddr *cliaddr;

11  if (argc == 2)
12   listenfd = Tcp_listen(NULL, argv[1], &addrlen);
13  else if (argc == 3)
14   listenfd = Tcp_listen(argv[1], argv[2], &addrlen);
15  else
16   err_quit("usage: serv06 [  ] ");
17  cliaddr = Malloc(addrlen);
18  Signal (SIGINT, sig_int);
19  for (;;) {
20   clilen = addrlen;
21   connfd = Accept(listenfd, cliaddr, &clilen);

22   Pthread_create(&tid, NULL, &doit, (void*)connfd);
23  }
24 }

25 void*
26 doit(void *arg)
27 {
28  void web_child(int);

29  Pthread_detach(pthread_self());
30  web_child((int)arg);
31  Close((int)arg);
32  return (NULL);
33 }

Цикл основного потока

19-23 Основной поток блокируется в вызове функции accept, и каждый раз, когда прибывает новое клиентское соединение, функцией pthread_create создается новый поток. Функция, выполняемая новым потоком, — это функция doit, а ее аргументом является присоединенный сокет.

Функция прочих потоков

25-33 Функция doit выполняется как отсоединенный (detached) поток, потому что основному потоку не требуется ждать ее завершения. Doit вызывает функцию web_child (см. листинг 30.5). Когда эта функция возвращает управление, присоединенный сокет закрывается.

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

ПРИМЕЧАНИЕ

В разделе 26.5 мы упомянули о трех вариантах преобразования функции, которая не является безопасной в многопоточной среде, в функцию, обеспечивающую требуемую безопасность. Функция web_child вызывает функцию readline, и версия, показанная в листинге 3.12, не является безопасной в многопоточной среде. На примере, приведенном в листинге 30.20, были испробованы вторая и третья альтернативы из раздела 26.5. Увеличение быстродействия при переходе от альтернативы 3 к альтернативе 2 составило менее одного процента, вероятно, потому, что функция readline использовалась лишь для считывания значения счетчика (5 символов) от клиента. Поэтому в данной главе для простоты мы использовали более медленную версию из листинга 3.11 для сервера с предварительным порождением потоков.

30.11. Сервер TCP с предварительным порождением потоков, каждый из которых вызывает accept

Ранее в этой главе мы обнаружили, что версии, в которых заранее создается пул дочерних процессов, работают быстрее, чем те, в которых для каждого клиентского запроса приходится вызывать функцию fork. Для систем, поддерживающих потоки, логично предположить, что имеется та же закономерность: быстрее сразу создать пул потоков при запуске сервера, чем создавать по одному потоку по мере поступления запросов от клиентов. Основная идея такого сервера заключается в том, чтобы создать пул потоков, каждый из которых вызывает затем функцию accept. Вместо того чтобы блокировать потоки в вызове accept, мы используем взаимное исключение, как в разделе 30.8. Это позволяет вызывать функцию accept только одному потоку в каждый момент времени. Использовать блокировку файла для защиты accept в таком случае бессмысленно, так как при наличии нескольких потоков внутри данного процесса можно использовать взаимное исключение.

В листинге 30.21 показан заголовочный файл pthread07.h, определяющий структуру Thread, содержащую определенную информацию о каждом потоке.

Листинг 30.21. Заголовочный файл pthread07.h

//server/pthread07.h
1 typedef struct {
2  pthread_t thread_tid; /* идентификатор потока */
3  long thread_count; /* количество обработанных запросов */
4 } Thread;
5 Thread *tptr; /* массив структур Thread */

6 int listenfd, nthreads;
7 socklen_t addrlen;
8 pthread_mutex_t mlock;

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

В листинге 30.22 показана функция main.

Листинг 30.22. Функция main для сервера TCP с предварительным порождением потоков

//server/serv07.c
 1 #include "unpthread.h"
 2 #include "pthread07.h"

 3 pthread_mutex_t mlock = PTHREAD_MUTEX_INITIALIZER;

 4 int
 5 main(int argc, char **argv)
 6 {
 7  int i;
 8  void sig_int(int), thread_make(int);

 9  if (argc == 3)
10   listenfd = Tcp_listen(NULL, argv[1], &addrlen);
11  else if (argc == 4)
12   listenfd = Tcp_1isten(argv[1], argv[2], &addrlen);
13  else
14   err_quit("usage: serv07 [  ] <#threads>");
15  nthreads = atoi(argv[argc - 1]);
16  tptr = Calloc(nthreads, sizeof(Thread));

17  for (i = 0; i < nthreads; i++)
18  thread_make(i); /* завершается только основной поток */

19  Signal(SIGINT, sig_int);

20  for (;;)
21   pause(); /* потоки все выполнили */
22 }

Функции thread_make и thread_main показаны в листинге 30.23.

Листинг 30.23. Функции thread_make и thread_main

//server/pthread07.c
 1 #include "unpthread.h"
 2 #include "pthread07.h"

 3 void
 4 thread_make(int i)
 5 {
 6  void *thread_main(void*);

 7  Pthread_create(&tptr[i].thread_tid, NULL, &thread_main, (void*)i);
 8  return; /* завершается основной поток */
 9 }

10 void*
11 thread_main(void *arg)
12 {
13  int connfd;
14  void web_child(int);
15  socklen_t clilen;
16  struct sockaddr *cliaddr;

17  cliaddr = Malloc(addrlen);

18  printf("thread %d starting\n", (int)arg);
19  for (;;) {
20   clilen = addrlen;
21   Pthread_mutex_lock(&mlock);
22   connfd = Accept(listenfd, cliaddr, &clilen);
23   Pthread_mutex_unlock(&mlock);
24   tptr[(int)arg].thread_count++;

25   web_child(connfd); /* обработка запроса */
26   Close(connfd);
27  }
28 }

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

7 Создаются потоки, каждый из которых выполняет функцию pthread_main. Единственным аргументом этой функции является порядковый номер потока.21-23 Функция thread_main вызывает функции pthread_mutex_lock и pthread_mutex_unlock соответственно до и после вызова функции accept.

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

В табл. 30.2 показано распределение значений счетчика thread_count структуры Thread, которые мы выводим с помощью обработчика сигнала SIGINT по завершении работы сервера. Равномерность этого распределения объясняется тем, что при выборе потока, который будет блокировать взаимное исключение, алгоритм планирования загрузки потоков последовательно перебирает все потоки в цикле.

ПРИМЕЧАНИЕ

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

30.12. Сервер с предварительным порождением потоков: основной поток вызывает функцию accept

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

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

Листинг 30.24. Заголовочный файл pthread08.h

//server/pthread08.h
 1 typedef struct {
 2  pthread_t thread_tid; /* идентификатор потока */
 3  long thread_count; /* количество обработанных запросов */
 4 } Thread;
 5 Thread *tptr; /* массив структур Thread */

 6 #define MAXNCLI 32
 7 int clifd[MAXNCLI], iget, iput;
 8 pthread_mutex_t clifd_mutex;
 9 pthread_cond_t clifd_cond;

Определение массива для записи дескрипторов присоединенных сокетов

6-9 Мы определяем массив clifd, в который главный поток записывает дескрипторы присоединенных сокетов. Свободные потоки из пула получают по одному дескриптору из этого массива и обрабатывают соответствующий запрос, iput — это индекс в данном массиве для очередного элемента, записываемого в него главным потоком, a iget — это индекс очередного элемента массива, передаваемого свободному потоку для обработки. Разумеется, эта структура данных, совместно используемая всеми потоками, должна быть защищена, и поэтому мы используем условную переменную и взаимное исключение.

В листинге 30.25 показана функция main.

Листинг 30.25. Функция main для сервера с предварительным порождением потоков

//server/serv08.c
 1 #include "unpthread.h"
 2 #include "pthread08.h"

 3 static int nthreads;
 4 pthread_mutex_t clifd_mutex = PTHREAD_MUTEX_INITIALIZER;
 5 pthread_cond_t clifd_cond = PTHREAD_COND_INITIALIZER;

 6 int
 7 main(int argc, char **argv)
 8 {
 9  int i, listenfd, connfd;
10  void sig_int(int), thread_make(int);
11  socklen_t addrlen, clilen;
12  struct sockaddr *cliaddr;

13  if (argc == 3)
14   listenfd = Tcp_listen(NULL, argv[1], &addrlen);
15  else if (argc == 4)
16   listenfd = Tcp_listen(argv[1], argv[2], &addrlen);
17  else
18   err_quit("usage: serv08 [  ] <#threads>");
19  cliaddr = Malloc(addrlen);

20  nthreads = atoi(argv[argc - 1]);
21  tptr = Calloc(nthreads, sizeof(Thread));
22  iget = iput = 0;

23  /* создание всех потоков */
24  for (i = 0; i < nthreads; i++)
25   thread_make(i); /* завершается только основной поток */

26  Signal(SIGINT, sig_int);

27  for (;;) {
28   clilen = addrlen;
29   connfd = Accept(listenfd, cliaddr, &clilen);

30   Pthread_mutex_lock(&clifd_mutex);
31   clifd[iput] = connfd;
32   if (++iput == MAXNCLI)
33    iput = 0;
34   if (iput == iget)
35    err_quit("iput = iget = %d", iput);
36   Pthread_cond_signal(&clifd_cond);
37   Pthread_mutex_unlock(&clifd_mutex);
38  }
39 }

Создание пула потоков

23-25 Функция thread_make создает все потоки.

Ожидание прихода клиентского соединения

27-38 Основной поток блокируется в вызове функции accept, ожидая появления нового соединения. При появлении этого соединения дескриптор присоединенного сокета записывается в следующий элемент массива clifd после блокирования взаимного исключения. Мы также следим, чтобы индекс iget не совпал со значением индекса iput, что укажет на недостаточно большой размер массива. Условная переменная сигнализирует о прибытии нового запроса, и взаимное исключение разблокируется, позволяя одному из потоков пула обслужить прибывший запрос.

Функции thread_make и thread_main показаны в листинге 30.26. Первая из них идентична функции, приведенной в листинге 30.23.

Листинг 30.26. Функции thread_make и thread_main

//server/pthread08.c
 1 #include "unpthread.h"
 2 #include "pthread08.h"

 3 void
 4 thread_make(int i)
 5 {
 6  void *thread_main(void*);

 7  Pthread_create(&tptr[i].thread_tid, NULL, &thread_main, (void*)i);
 8  return; /* завершается основной поток */
 9 }

10 void*
11 thread_main(void *arg)
12 {
13  int connfd;
14  void web_child(int);

15  printf("thread %d starting\n", (int)arg);
16  for (;;) {
17   Pthread_mutex_lock(&clifd_mutex);
18   while (iget == iput)
19    Pthread_cond_wait(&clifd_cond, &clifd_mutex);
20   connfd = clifd[iget]; /* присоединенный сокет, который требуется
                              обслужить */
21   if (++iget == MAXNCLI)
22    iget = 0;
23   Pthread_mutex_unlock(&clifd_mutex);
24   tptr[(int)arg].thread_count++;

25   web_child(connfd); /* обработка запроса */
26   Close(connfd);
27  }
28 }

Ожидание присоединенного сокета, который требует обслуживания

17-26 Каждый поток из пула пытается блокировать взаимное исключение, блокирующее доступ к массиву clifd. Если после того, как взаимное исключение заблокировано, оказывается, что индексы iput и iget равны, то вызывается функция pthread_cond_wait, и поток переходит в состояние ожидания, так как ему пока нечего делать. После прибытия очередного клиентского запроса основной поток вызывает функцию pthread_cond_signal, выводя тем самым из состояния ожидания поток, заблокировавший взаимное исключение. Когда этот поток получает соединение, он вызывает функцию web_child.

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

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

30.13. Резюме

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

0. Последовательный сервер (точка отсчета — управление процессом отсутствует).

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

2. Предварительное порождение дочерних процессов, каждый из которых вызывает функцию accept.

3. Предварительное порождение дочерних процессов с блокировкой файла для защиты функции accept.

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

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

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

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

8. Предварительное порождение потоков, основной поток вызывает функцию accept.

Резюмируя материал этой главы, можно сделать несколько комментариев.

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

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

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

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

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

■ Использование потоков, как правило, дает больший выигрыш во времени, чем использование процессов. Но выбор между версиями 1 и 6 (один дочерний процесс на каждый запрос и один поток на каждый запрос) зависит от свойств операционной системы и от того, какие еще программы задействованы в обслуживании клиентских запросов. Например, если сервер, принимающий клиентское соединение, вызывает функции fork и exec, то может оказаться быстрее породить с помощью функции fork процесс с одним потоком, чем процесс с несколькими потоками.

Упражнения

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

2. Попробуйте изменить сервер из раздела 30.9 таким образом, чтобы использовать дейтаграммный доменный сокет Unix вместо потокового сокета домена Unix. Что при этом изменяется?

3. Запустите клиент и те серверы из рассмотренных в этой главе, которые позволяет запустить конфигурация вашей системы, и сравните полученные результаты с приведенными в тексте.

Глава 31