if (val != getprio(0))
if (setprio(0, val) == -1)
perror("priority isn't a valid"), exit(EXIT_FAILURE);
break;
case 'n':
if (sscanf(optarg, "%i", &val) != 1)
perror("parse command line failed"), exit(EXIT_FAILURE);
if (val > 0)nsingl *= val;
break;
case 'a':
if (sscanf(optarg, "%i", &val) != 1)
perror("parse command line failed"), exit(EXIT_FAILURE);
if (val > 0) nall = val;
break;
default:
exit(EXIT_FAILURE);
}
}
// ... вот здесь начинается собственно сама программа.
if (nthr > 1)
cout << "Multi-thread evaluation, thread number = " << nthr;
else cout << "Single-thread evaluation";
cout << " , priority level: " << getprio(0) << endl;
__clockperiod clcout;
ClockPeriod(CLOCK_REALTIME, NULL, &clcout, 0);
// интервал диспетчеризации - 4 периода tickslice
// (системного тика):
cout << "rescheduling = \t"
<< clcout.nsec * 4 / 1000000. << endl;
// калибровка времени выполнения в одном потоке
const int NCALIBR = 512;
uint64_t tmin = 0, tmax = 0;
tmin = ClockCycles();
workproc(NCALIBR);
tmax = ClockCycles();
cout << "calculating = \t"
<< cycle2milisec(tmax - tmin) / NCALIBR << endl;
// а теперь контроль времени многих потоков
if (pthread_barrier_init(&bstart, NULL, nthr) != EOK)
perror("barrier init"), exit(EXIT_FAILURE);
if (pthread_barrier_init(&bfinish, NULL, nthr + 1) != EOK)
perror("barrier init"), exit(EXIT_FAILURE);
trtime = new interv[nthr];
int cur = 0, prev = 0;
for (int i = 0; i < nthr; i++) {
// границы участков работы для каждого потока.
cur = (int)floor((double)nall / (double)nthr * (i + 1) + .5);
prev = (int)floor((double)nall / (double)nthr * i + 5);
if (pthread_create(NULL, NULL, threadfunc, (void*)(cur - prev)) != EOK)
perror("thread create"), exit(EXIT_FAILURE);
}
pthread_barrier_wait(&bfinish);
for (int i=0; i < nthr; i++ ) {
tmin = (i == 0) ? trtime[0].s : __min(tmin, trtime[i].s);
tmax = ( i == 0 ) ? trtime[0].f : __max(tmax, trtime[i].f);
}
cout << "evaluation = \t"
<< cycle2milisec(tmax - tmin) / nall << endl;
pthread_barrier_destroy(&bstart);
pthread_barrier_destroy(&bfinish);
delete trtime;
exit(EXIT_SUCCESS);
}
Логика этого приложения крайне проста:
• Есть некоторая продолжительная по времени рабочая функция (workproc), выполняющая массированные вычисления.
• Многократно (это число определяется ключом запуска а) выполняется рабочая функция. Хорошо (то есть корректнее), если время ее единичного выполнения, которое задается ключом n, больше интервала диспетчеризации системы (в системе установлена диспетчеризация по умолчанию - круговая, или карусельная).
• Весь объем этой работы делится поровну (или почти поровну) между несколькими (ключ t) потоками.
• Сравниваем усредненное время единичного выполнения рабочей функции для разного числа выполняющих потоков (в выводе "calculating" - это время эталонного вычисления в одном главном потоке, a "evaluation" - время того же вычисления, но во многих потоках).
• Для того чтобы иметь еще большую гибкость, предоставляется возможность переопределять приоритет, под которым в системе все это происходит (ключ p).
Вот самая краткая сводка результатов (1-я строка вывода переносится для удобства чтения):
# t1 -n1 -t1000 -a2000
Multi-thread evaluation, thread number = 1000, priority level: 10
rescheduling = 3.99939
calculating = 1.04144
evaluation = 1.08001
# t1 -n1 -t10000 -a20000
Multi-thread evaluation, thread number = 10000, priority level: 10
rescheduling = 3.99939
calculating = 1.04378
evaluation = 1.61946
# t1 -n5 -a2000 -t1
Single-thread evaluation, priority level: 10
rescheduling = 3.99939
calculating = 5.07326
evaluation = 5.04726
# t1 -n5 -a2000 -t2
Multi-thread evaluation, thread number = 2, priority level: 10
rescheduling = 3.99939
calculating = 5.06309
evaluation = 5.04649
# t1 -n5 -a2000 -t20
Multi-thread evaluation, thread number = 20, priority level: 10
rescheduling = 3.99939
calculating = 5.06343
evaluation = 4.96956
# t1 -n5 -p51 -a512 -t1
Single-thread evaluation, priority level: 51
rescheduling = 3.99939
calculating = 4.94502
evaluation = 4.94511
# t1 -n5 -р51 -a512 -t11
Multi-thread evaluation, thread number = 11, priority level: 51
rescheduling = 3.99939
calculating = 4.94554
evaluation = 4.94549
# t1 -n5 -p51 -a512 -t111
Multi-thread evaluation, thread number = 111, priority level: 51
rescheduling = 3.99939
calculating = 5.02755
evaluation = 4.94487
# t1 -n5 -p51 -a30000 -t10000
Multi-thread evaluation, thread number = 10000, priority level: 51
rescheduling = 3.99939
calculating = 4.94575
evaluation = 5.31224
Краткий и, возможно, несколько парадоксальный итог этого теста может звучать так: при достаточно высоком уровне приоритета (выше 12–13, когда на его выполнение не влияют процессы обслуживания клавиатуры, мыши и др.) время выполнения в "классическом" последовательном коде и в многопоточном коде (где несколько тысяч потоков!) практически не различаются. Различия не более 8%, причем в обе стороны, что мы склонны считать "статистикой эксперимента". К обсуждению этого якобы противоречащего здравому смыслу феномена мы еще вернемся.
А пока посмотрим на текст примера, что и является нашей главной дачей. Обсуждаемое приложение вполне работоспособно в QNX с большой вероятностью в большинстве других UNIX-систем, но в Linux оно завершится аварийно. Причина этого кроется в операторах
int id = pthread_self() - 2;
trtime[id].s = ...
Это дает повод лишний раз обратиться к вопросу "POSIX-совместимости". POSIX описывает, что TID потока присваивается: а) в рамках процесса, которому принадлежит поток; б) начиная со значения 1, соответствующего главному потоку приложения. В Linux, выполняющем и pthread_create(), и fork() через единый системный вызов _clone() сделано небольшое "упрощение", навязанное в том числе и гонкой за повышением производительности: TID присваиваются из единого ряда PID. И сразу же "вылезает" несовместимость, ведущая к аварийному завершению показанного выше приложения. В последних редакциях ядра Linux делаются изменения по приведению механизмов параллельности к общей POSIX-модели.
Этот момент сам по себе достаточно интересен, поэтому остановимся на нем подробнее, для чего создадим простейший программный тест:
#define TCNT 10
void * test(void *in) {
printf("pid %ld, tid %ld\n", getpid(), pthread_self());
return NULL;
}
int main(int argc, char **argv, char **envp) {
pthread_t tld[TCNT];
int i, status;
for (i=0; i < TCNT; i++) {
status = pthread_create(&tid[i], NULL, test, NULL);
if (status != 0)
err(EXIT_FAILURE, "pthread_create()");
}
return(EXIT_SUCCESS);
}
Результаты выполнения этого теста в нескольких POSIX-совместимых ОС различны и весьма красноречивы:
$ uname -sr Linux 2.4.21-0.13mdk
$ ./test_pthread
pid 2008, tid 16386
pid 2009, tid 32771
pid 2010, tid 49156
pid 2011, tid 65541
pid 2012, tid 81926
pid 2013, tid 98311
pid 2014, tid 114696
pid 2015, tid 131081
pid 2016, tid 147466
pid 2017, tid 163851
А вот результат эволюции в направлении POSIX при переходе от ядра Linux 2.4.x к 2.6.x (алгоритм формирования TID все еще остается загадочным, но уже выполняются требования POSIX о выделении TID в рамках единого PID):
$ uname -sr Linux 2.6.3-7mdk
$ ./test_pthread
pid 13929, tid 1083759536
pid 13929, tid 1092156336
pid 13929, tid 1100549040
pid 13929, tid 1108941744
pid 13929, tid 1117334448
pid 13929, tid 1125727152
pid 13929, tid 1134119856
pid 13929, tid 1142512560
pid 13929, tid 1150905264
pid 13929, tid 1159297968
И наконец, тот же тест, выполненный в QNX 6.2.1:
# uname -a
QNX home 6.2.1 2003/01/08-14.50:46est х86рс x86
# ptid
pid 671779, tid 2
pid 671779, tid 3
pid 671779, tid 4
pid 671779, tid 5
pid 671779, tid 6
pid 671779, tid 7
pid 671779, tid 8
pid 671779, tid 9
pid 671779, tid 10
pid 671779, tid 11
Спорадическая диспетчеризация
Системы реального времени принципиально отличаются от систем общего назначения тем, что для таких систем важна не только корректность выполнения возложенных на них функций, но и время, за которое эти функции реализуются. Можно даже сказать, что для задач реального времени опоздание с выполнением практически эквивалентно невыполнению задачи: требуемая реакция или управляющее воздействие не поступили в срок. Предельный срок, в который задача реального времени должна быть выполнена, называют критическим сроком обслуживания (deadline).
Если система реального времени реализуется как многопоточная система (а в настоящее время такой вариант рассматривается фактически как стандартный), то при ее разработке зачастую возникает проблема определения того, действительно ли все задачи реального времени, конкурирующие в системе за вычислительный ресурс, успевают исполниться в их критический срок обслуживания.
Примечание
Здесь мы следуем "классической" модели обсуждения из области систем реального времени, хотя уместнее было бы акцентировать внимание не на абсолютной минимизации времени приложения, а именно на том, что приложение обязано "уложиться" в некоторый критический интервал времени (см. выше). Величина же того, насколько быстро приложение выполнит свои критические функции (если оно укладывается в критический интервал) по принципу "меньше - больше", практически уже не имеет никакого значения. Из этого не совсем четкого толкования сложился общий стереотип, состоящий в том, что системы реального времени (в частности, операционные системы реального времени) принято считать "быстрыми" (в том смысле, что они потенциально могут исполнять аналогичные функции быстрее, чем системы общего назначения). Этот взгляд в корне ошибочен: системы реального времени в общем случае, скорее, будут даже "медленнее", чем системы общего назначения, за счет более тщательной отработки операций, например диспетчеризации и переключений контекстов. Во многих случаях можно ожидать, что при многократном выполнении участка кода средняя величина времени его выполнения в ОС общего назначения будет ниже, но вот дисперсия этой средней величины будет намного ниже в системах реального времени.
На сегодняшний день существует несколько систем математического анализа временных характеристик систем реального времени, призванных помочь разработчику в построении системы, распределении приоритетов между задачами и, в конечном счете, определении диспетчеризуемости системы. Систему называют диспетчеризуемой, если все ее задачи укладываются в свои сроки критического обслуживания.
Одна из наиболее известных систем математического анализа временных характеристик систем реального времени с периодическим поступлением запросов на выполнение задач называется "Частотно-монотонный анализ" (ЧМА - Rate Monotonic Analyzing) [13]. Свое название эта система получила от ее основного принципа: "Чем короче период поступления (выше частота) задачи, тем выше ее приоритет". Как уже говорилось, ЧМА предназначен для анализа систем реального времени, в которых каждая задача реального времени обрабатывается со своим периодом, причем еще одним ограничением ЧМА является условие, что период поступления задачи является также и ее критическим сроком обслуживания. В настоящее время появился ряд новых методов анализа характеристик систем реального времени для случаев критических сроков обслуживания, больших или меньших периода поступления, но здесь мы не будем на них останавливаться.
К сожалению, практически невозможно создать эффективную методику анализа систем с полностью случайными сроками поступления задач реального времени. Однако на практике такие ситуации в чистом виде встречаются не особо часто. В отличие от задач с полностью случайным сроком поступления, в математическом анализе систем реального времени рассматриваются так называемые спорадические задачи, то есть задачи, последующий срок поступления которых может наступить не ранее некоторого времени после их предыдущего поступления.
Планирование обслуживания таких задач можно свести к планированию периодических задач и, таким образом, провести для них анализ диспетчеризуемости. Для этого теория ЧМА предлагает введение дополнительной периодической задачи (называемой спорадический сервер), которая проводит обслуживание непериодических (спорадических) задач.
Алгоритм работы такого сервера [13] следующий:
• Шаг 1. Если спорадический запрос прибывает и сервер не может его обработать, потому что уже занят или не имеет свободного ресурса вычислений, запрос будет поставлен в очередь обработки.
• Шаг 2. Если получен спорадический запрос и сервер может его обработать, он делает следующее:
• Шаг 2а. Выполняется до служебного завершения или истощения ресурса вычисления.
• Шаг 2с. Уменьшает текущий ресурс вычисления на используемое количество и на столько же увеличивает его ресурс вычисления в точке пополнения.
Для реализации теоретически обобщенной модели спорадического сервера в качестве механизма, реализующего эту модель, в QNX 6.2.1 была введена специализированная дисциплина диспетчеризации - спорадическая.