Введение в QNX/Neutrino 2

 thread_pool_start(tpp);

 fprintf(stderr,

  "%s: возврат из thread_pool_start; errno %s\n",

  progname, strerror(errno));

 sleep(3000);

 exit(EXIT_FAILURE);

}

После установки параметров мы вызываем функцию thread_pool_create() для создания пула потоков. Эта функция возвращает указатель на управляющую структуру пула потоков (tpp), который мы проверяем на равенство NULL (что указало бы на ошибку). И, наконец, мы вызываем функцию thread_pool_start(), передав ей эту самую управляющую структуру tpp.

Я указал флаг POOL_FLAG_USE_SELF, что означает, что поток, вызвавший функцию thread_pool_start(), будет рассматриваться как доступный для ввода в пул. Таким образом, на момент старта пула в нем есть только один поток. Поскольку значение параметра lo_water равно 3, библиотека немедленно создаст еще increment потоков (в нашем случае — 2). С этого момента в пуле будет три (3) потока, и все они будут находиться в режиме блокирования. Условие по параметру lo_water удовлетворено, потому что число потоков в режиме блокирования действительно не меньше lo_water, условие по параметру hi_water удовлетворено, потому что число потоков в режиме блокирования действительно не больше hi_water; и, наконец, также удовлетворено условие по параметру maximum, потому что общее число потоков не превышает его значения. Допустим теперь, что один из потоков, находящихся в режиме блокирования, разблокируется (например, в серверном приложении — при получении сообщения). Это означает, что один из трех потоков перейдет из режима блокирования в режим обработки. Счетчик блокированных потоков уменьшится, и его значение упадет ниже значения параметра lo_water. Это переключит триггер lo_water и заставит библиотеку создать ещё increment (2) потоков. Таким образом, у нас будет всего 5 потоков (4 в режиме блокирования, и 1 — в режиме обработки).

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

Событие	Режим обработки	Режим блокирования	Всего потоков
Исходное состояние	0	1	1
Срабатывание триггера lo_water	0	3	3
Разблокирование	1	2	3
Срабатывание триггера lo_water	1	4	5
Разблокирование	2	3	5
Разблокирование	3	2	5
Срабатывание триггера lo_water	3	4	7
Разблокирование	4	3	7
Разблокирование	5	2	7
Срабатывание триггера lo_water	5	4	9
Разблокирование	6	3	9
Разблокирование	7	2	9
Срабатывание триггера lo_water	7	3	10
Разблокирование	8	2	10
Разблокирование	9	1	10
Разблокирование	10	0	10

Видно, что библиотека проверяет параметр lo_water, и по мере необходимости увеличивает число потоков на значение параметра increment, но только до тех пор, пока число потоков не достигнет предельного значения — параметра maximum (именно поэтому число в столбце «Всего потоков» никогда не превышает 10, даже когда условие по параметру lo_water перестает выполняться).

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

Событие	Режим обработки	Режим блокирования	Всего потоков
Завершение обработки	9	1	10
Завершение обработки	8	2	10
Завершение обработки	7	3	10
Завершение обработки	6	4	10
Завершение обработки	5	5	10
Завершение обработки	4	6	10
Завершение обработки	3	7	10
Завершение обработки	2	8	10
Срабатывание триггера hi_water	2	7	9
Завершение обработки	1	8	9
Срабатывание триггера hi_water	1	7	9
Завершение обработки	0	8	8
Срабатывание триггера hi_water	0	7	7