Если вы никогда ранее не сталкивались с таким типом устройства сервера (несколько процессов, вызывающих функцию
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 <sys/mman.h>
3 /* Размещаем массив "nchildren" длинных целых чисел
4 * в совместно используемой области памяти.
5 * Эти числа используются как счетчики количества
* клиентов, обслуженных данным дочерним процессом,
Мы используем неименованное отображение в память, если оно поддерживается (например, в 4.4BSD), или отображение файла
/dev/zero
(например, SVR4). Поскольку массив создается функцией
mmap
до того, как родительский процесс порождает дочерние, этот массив затем используется совместно родительским и всеми дочерними процессами, созданными функцией