Олег Цилюрик - QNX/UNIX: Анатомия параллелизма

Еще раз подчеркнем достаточно очевидную вещь: дисциплина диспетчеризации определяется относительно потока и на уровне потока (но не процесса). Проследить за дисциплиной диспетчеризации (и убедиться в справедливости утверждения предыдущей фразы) можно командой 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] В документации неоднократно упоминается еще одна дисциплина — «адаптивная» ( SCHED_ADAPTIVE ), и даже детально описывается, «как она работает». Видимо, это можно отнести только к тому, что корректировка обширной документации отстает от развития самой системы. На конференции «QNX-Россия 2003» на вопрос по поводу ADAPTIVE-диспетчеризации представители QSSL отвечали так: «Этот вид диспетчеризации был в QNX 4.xx, а в QNX 6.x вместо него введена более продвинутая техника SPORADIC-диспетчеризации». Тем не менее более продвинутая спорадическая диспетчеризация не позволяет абсолютно точно выразить логику адаптивной. дисциплины диспетчеризации: очередь потоков равных приоритетов (FIFO — first in first out; еще в ходу термин «невытесняющая»), карусельная (RR — round-robin) и спорадическая. Рассмотрим фрагмент их определения в файле :

#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

int sched_rr_get_interval(pid_t pid, struct timespec* interval);

где pid— это PID процесса, для которого определяется квант времени, как и для многих других подобных функций. Если PID = 0, вызов относится к текущему процессу;

interval— указатель на структуру timespec(стандарт POSIX 1003.1):

#include

struct timespec {

time_t tv_sec; // значение секунд

long tv_nsec; // значение наносекунд

}

При успешном выполнении функция sched_rr_get_interval()возвращает 0, в противном случае -1.

Две другие функции, часто удобные для работы со структурой timespec:

#include

void nsec2timespec(struct timespec *timespec_p, _uint64 nsec);

— это преобразование интервала, выраженного в наносекундах (nsec), в структуру timespec(«выходной» параметр вызова timespec_p);

#include

_uint64 timespec2nsec(const struct timespec* ts);

— это преобразование структуры timespec в значение, выраженное в наносекундах (это функция из native API QNX).

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

Часто задают вопрос: «А как много потоков целесообразно делать? Не сколько снижается эффективность многопоточной программы за счет диспетчеризации потоков?» С другой стороны, в литературе часто встречаются (достаточно голословные, на качественном уровне) утверждения, что многопоточная программа будет заметно уступать в фиктивности своему последовательному (в одном потоке) эквиваленту. Проверим это на реальной задаче:

#include

#include

#include

#include

#include

#include

#include

#include

#include

#include

#include

// преобразование процессорных циклов в миллисекунды:

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[]) {

// здесь только обработка многочисленных ключей...