Олег Цилюрик - QNX/UNIX: Анатомия параллелизма
Диспетчеризация потоков
Каждому потоку, участвующему в процессе диспетчеризации, соответствует экземпляр структуры, определенной в файле <sys/target_nto.h>, в котором находятся все фундаментальные для ОС QNX определения:
struct sched_param {
_INT32 sched_priority;
_INT32 sched_curpriority;
union {
_INT32 reserved[8];
struct {
_INT32 __ss_low_priority;
_INT32 __ss_max_repl;
struct timespec __ss_repl_period;
struct timespec __ss_init_budget;
} __ss;
} __ss_un;
};
#define sched_ss_low_priority __ss_un.__ss.__ss_low_priority
#define sched_ss_max_repl __ss_un.__ss.__ss_max_repl
#define sched_ss_repl_period __ss_un.__ss.__ss_repl_period
#define sched_ss_init_budget __ss_un.__ss.__ss_init_budget
Все, что определяется внутри union __ss_un, имеет отношение только к спорадической диспетчеризации (спорадическая диспетчеризация была введена значительно позже других, и ей будет уделено достаточно много внимания). Для всех остальных типов диспетчеризации потока это поле заполняется фиктивным полем reserved, и именно так в укороченном виде) определялась структура диспетчеризации в версии QNX 6.1.
Сейчас нас интересуют начальные поля этой структуры, не зависящие от типа диспетчеризации потока:
sched_priority — статический приоритет, который присваивается потоку при его создании и который может быть программно изменен по ходу выполнения потока;
sched_curpriority — текущий приоритет, с которым выполняется (и согласно которому диспетчеризируется) данный поток в текущий момент времени. Это значение приоритета образуется системой на основе заданного статического приоритета, но оно может динамически изменяться системой, например при отработке дисциплин наследования приоритетов или граничных приоритетов для потока. Программа не имеет средств воздействия на это значение[20], но может его считывать.
Еще раз подчеркнем достаточно очевидную вещь: дисциплина диспетчеризации определяется относительно потока и на уровне потока (но не процесса). Проследить за дисциплиной диспетчеризации (и убедиться в справедливости утверждения предыдущей фразы) можно командой pidin. Вот несколько строк ее вывода, относящиеся к составным частям самой системы:
pid tid name prio STATE Blocked
1 1 6/boot/sys/procnto 0f READY
1 2 6/boot/sys/procnto 10r RUNNING
...
1 5 6/boot/sys/procnto 63r RECEIVE 1
...
1 9 6/boot/sys/procnto 6r NANOSLEEP
...
6 1 roc/boot/devb-eide 10o SIGWAITINFO
В поле prio указывается приоритет (текущий; возможно, последнее из унаследованных значений!) каждого потока с установленной для него дисциплиной диспетчеризации: f — FIFO, r — RR, o — OTHER, s — SPORADIC.
В системе на сегодняшний день реализованы три[21] дисциплины диспетчеризации: очередь потоков равных приоритетов (FIFO — first in first out; еще в ходу термин «невытесняющая»), карусельная (RR — round-robin) и спорадическая. Рассмотрим фрагмент их определения в файле <sched.h>:
#if defined(__EXT_QNX)
#define SCHED_NOCHANGE 0
#endif
#define SCHED_FIFO 1
#define SCHED_RR 2
#define SCHED_OTHER 3
#if defined(__EXT_QNX)
#define SCHED_SPORADIC 4 /* Approved 1003.1d D14 */
#define SCHED_ADJTOHEAD 5 /* Move to head of ready queue */
#define SCHED_ADJTOTAIL 6 /* Move to tail of ready queue */
#define SCHED_MAXPOLICY 6 /* Maximum valid policy entry */
#endif
Все дисциплины диспетчеризации, кроме спорадической, достаточно полно описаны в литературе [1], поэтому мы лишь перечислим их отличительные особенности:
1. FIFO — это та дисциплина диспетчеризации, которая в литературе по Windows 3.1/3.11 называлась «невытесняющей многозадачностью» (или «кооперативной»). Здесь выполнение потока не прерывается потоками равного приоритета до тех пор, пока сам поток «добровольно» не передаст управление, например вызовом sched_yield() (часто для этой цели используется косвенный эффект вызовов delay(), sleep() и им подобных). В других источниках такой способ диспетчеризации называют очередями потоков равных приоритетов.
2. RR — это та дисциплина диспетчеризации, которая в Windows 98/NT/XP именуется «вытесняющей многозадачностью»; еще в литературе для нее используется термин «режим квантования времени».
Поток работает непрерывно только в течение предопределенного кванта времени. (В нескольких местах документации утверждается, что значение этого кванта времени составляет 4 системных тика (time-slice), что в QNX 6.2.1 по умолчанию составляет 4 миллисекунды, и только в одном месте документации говорится, что квант диспетчеризации составляет 50 миллисекунд; это определенное разночтение. Справедливым является именно первое утверждение.)
После истечения отведенного ему кванта времени поток вытесняется потоком равного приоритета (при отсутствии других потоков этим новым потоком может быть и только что вытесненный, то есть его выполнение будет продолжено, но передиспетчеризация тем не менее происходит). Установленный квант времени диспетчеризации может быть получен вызовом (стандарт POSIX 1003.1):
#include <sched.h>
int sched_rr_get_interval(pid_t pid, struct timespec* interval);
где pid — это PID процесса, для которого определяется квант времени, как и для многих других подобных функций. Если PID = 0, вызов относится к текущему процессу;
interval — указатель на структуру timespec (стандарт POSIX 1003.1):
#include <time.h>
struct timespec {
time_t tv_sec; // значение секунд
long tv_nsec; // значение наносекунд
}
При успешном выполнении функция sched_rr_get_interval() возвращает 0, в противном случае -1.
ПримечаниеДве другие функции, часто удобные для работы со структурой timespec:
#include <time.h>
void nsec2timespec(struct timespec *timespec_p, _uint64 nsec);
— это преобразование интервала, выраженного в наносекундах (nsec), в структуру timespec («выходной» параметр вызова timespec_p);
#include <time.h>
_uint64 timespec2nsec(const struct timespec* ts);
— это преобразование структуры timespec в значение, выраженное в наносекундах (это функция из native API QNX).
3. Спорадическая диспетчеризация — это гораздо более развитая форма «вытесняющей многозадачности», численные характеристики которой (время кванта, численные значения приоритетов и др.) могут детально параметризироваться и даже динамически изменяться по ходу выполнения. Подробнее спорадическая диспетчеризация рассмотрена далее.
Часто задают вопрос: «А как много потоков целесообразно делать? Не сколько снижается эффективность многопоточной программы за счет диспетчеризации потоков?» С другой стороны, в литературе часто встречаются (достаточно голословные, на качественном уровне) утверждения, что многопоточная программа будет заметно уступать в фиктивности своему последовательному (в одном потоке) эквиваленту. Проверим это на реальной задаче:
Множественные потоки в едином приложении#include <stdlib.h>
#include <stdio.h>
#include <iostream.h>
#include <unistd.h>
#include <limits.h>
#include <pthread.h>
#include <inttypes.h>
#include <sys/neutrino.h>
#include <sys/syspage.h>
#include <errno.h>
#include <math.h>
// преобразование процессорных циклов в миллисекунды:
static double cycle2milisec(uint64_t ccl) {
const static double s2m = 1.E+3;
// это скорость процессора
const static uint64_t
cps = SYSPAGE_ENTRY(qtime)->cycles_per_sec;
return (double)ccl * s2m / (double)cps;
}
static int nsingl = 1;
// рабочая функция, которая имитирует вычисления:
void workproc(int how) {
const int msingl = 30000;
for (int j = 0; j < how; j++)
for (uint64_t i=0; i < msingl * nsingl; i++)
i = (i + 1) - 1;
}
static pthread_barrier_t bstart, bfinish;
struct interv { uint64_t s, f; };
interv *trtime;
void* threadfunc(void* data) {
// все потоки после создания должны "застрять" на входном
// барьере, чтобы потом одновременно "сорваться" в исполнение
pthread_barrier_wait(&bstart);
int id = pthread_self() - 2;
trtime[id].s = ClockCycles();
workproc((int)data);
trtime[id].f = ClockCycles();
pthread_barrier_wait(&bfinish);
return NULL;
}
int main(int argc, char *argv[]) {
// здесь только обработка многочисленных ключей...
int opt, val, nthr = 1, nall = SHRT_MAX;
while ((opt = getopt(argc, argv, "t:n:p:a:")) != -1) {
