QNX/UNIX: Анатомия параллелизма - [8]
Любой процесс может содержать произвольное количество потоков, но не менее одного и не более 32 767 (для QNX версии 6.2). Совокупность данных, необходимых для выполнения любого из потоков процесса, а также контекст текущего выполняемого потока называются контекстом процесса.
Согласно ранним «каноническим» спецификациям UNIX [3] ОС должна поддерживать не менее 4095 отдельных процессов (точнее 4096, из которых 0-вой представляет собой процесс, загружающий ОС и, возможно, реализующий в дальнейшем функции ядра). Во всей документации ОС QNX нам не удалось найти предельное значение этого параметра. Но если из этого делается «тайна мадридского двора», то наша задача — найти это значение:
>int main(int argc, char* argv[]) {
> unsigned long n = 1;
> pid_t pid;
> while((pid = fork()) >= 0) {
> n++;
> if (pid > 0) {
> waitpid(pid, NULL, WEXITED);
> exit(EXIT_SUCCESS);
> }
> }
> if (pid == -1) {
> cout << "exit with process number: << n << " - " << flush;
> perror(NULL);
> }
>}
Этот достаточно непривычный по внешнему виду код дает нам следующий результат:
># pn
>exit with process number: 1743 - Not enough memory
Системному сообщению о недостатке памяти достаточно трудно верить: чуть меньше 4 Кбайт программного кода в своих 1743 «реинкарнациях» требуют не более 6,6 Мбайт для своего размещения при свободных более 230 Мбайт в системе, в которой мы испытывали это приложение. Оставим это на совести создателей ОС QNX.
В продолжение нашей основной темы любопытно рассмотреть результаты вывода команды >pidin, а именно последнюю ее строку с информацией о последнем запущенном в системе процессе:
• до запуска обсуждаемого приложения:
>4/366186 1 /photon/bin/phcalc 10r REPLY 241691
• и после его завершения:
>54652947 1 bin/pidin 10r REPLY 1
Легко видеть, что разница PID, равная 54652947 – 47366186 = 7286761, никак не является числом активированных на этом временном промежутке процессов, которое равно 1743. Поэтому к численным значениям PID нужно относиться с заметной осторожностью: это не просто инкрементированное значение числа запущенных процессов, схема формирования PID заметно сложнее.
В любом случае мы можем принять, что в ОС QNX Neutrino 6.2.1, как и в других «канонических» UNIX, количество процессов (если, конечно, эта ОС не дает нам более вразумительных оценок) ограничено цифрой 4095. Видно, что общее количество независимых потоков исполнения в системе может достигать совершенно ошеломляющей цифры. Но как бы много потоков мы ни создавали, им все равно придется конкурировать за доступ к самому главному ресурсу — процессору. В настоящее время реализованные в QNX дисциплины диспетчеризации работают над суммарным полем всех потоков в системе (рис. 2.1): если в системе выполняется N процессов и i-й процесс реализует M>i потоков, то в очередях диспетчеризации одновременно задействовано
Рис. 2.1. Диспетчеризация процессов
На рис. 2.1 изображены два процесса, выполняющиеся под управлением системы. Каждый процесс создал внутри себя различное количество потоков равного приоритета. Обратите внимание, что фактическая диспетчеризация производится не между процессами, а между потоками процессов, даже если иногда для простоты говорят «диспетчеризация процессов». Потоки объединены в циклическую очередь диспетчеризации, и пунктирная линия показывает порядок, в котором (в направлении стрелки) они будут поочередно получать квант времени.
Если ни один из потоков не будет выполнять блокирующих операций (>read(), >delay(), >accept(), >MsgSend() и множество других), что реально встречается крайне редко, то показанный порядок «следования» потоков при диспетчеризации будет сохраняться неограниченно долго. Как только поток выполнит блокирующий вызов, он будет удален из очереди готовых к выполнению потоков, а после завершения вызова возвращен в очередь, причем (что характерно!) в голову очереди. После этого топология «петли» (порядок чередования), показанной на рисунке пунктиром, может произвольным образом измениться.
Из рисунка хорошо видно, что при диспетчеризации «в рамках системы» (об этом мы будем говорить позже) два запущенных процесса будут выполняться в неравных условиях: на каждый полный цикл диспетчеризации программный код, выполняющийся в рамках процесса А, будет получать 1 квант времени, а код в процессе B — 3 кванта.
Стандарт POSIX, определяя названную стратегию диспетчеризации константой >PTHREAD_SCOPE_SYSTEM, предусматривает и другую стратегию, обозначаемую константой >PTHREAD_SCOPE_PROCESS, когда потоки конкурируют за процессорный ресурс в пределах процесса, к которому они принадлежат (в Sun Solaris первой стратегии соответствуют «bound thread», а второй — «unbound thread»). Реализация стратегии >PTHREAD_SCOPE_PROCESS связана с серьезными трудностями. Насколько нам известно, в настоящее время из числа широко распространенных ОС она реализована только в Sun Solaris. В QNX для совместимости с POSIX даже присутствуют системные вызовы относительно стратегии диспетчеризации:
>int pthread_attr_setscope(pthread_attr_t* attr, int scope);
>int pthread_attr_getscope(const pthread_attr_t* attr, int* scope);
