Олег Цилюрик - QNX/UNIX: Анатомия параллелизма
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) {
switch(opt) {
case 't':
if (sscanf(optarg, "%i", &val) != 1)
perror("parse command line failed"), exit(EXIT_FAILURE);
if (val > 0 && val <= SHRT_MAX) nthr = val;
break;
case 'p':
if (sscanf(optarg, "%i", &val) != 1)
perror("parse command line failed"), exit(EXIT_FAILURE);
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-модели.
Этот момент сам по себе достаточно интересен, поэтому остановимся на нем подробнее, для чего создадим простейший программный тест[22]:
#define TCNT 10
void * test(void *in) {
printf("pid %ld, tid %ldn", 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
