«Легковесность» потока
«Легковесность» потока
Вот теперь, завершив краткий экскурс использования процессов и потоков, можно вернуться к вопросу, который вскользь уже звучал по ходу рассмотрения: почему и в каком смысле потоки часто называют «легкими процессами» (LWP — lightweight process)?
Выполним ряд тестов по сравнительной оценке временных затрат на создание процесса и потока. Начнем с процесса (файл p2-1.cc):
Затраты на порождение нового процесса
struct mbyte { // мегабайтный блок данных
#pragma pack(1)
uint8_t data[1024 * 1024];
#pragma pack(4)
};
int main(int argc, char *argv[]) {
mbyte *blk = NULL;
if (argc > 1 && atoi(argv[1]) > 0) {
blk = new mbyte[atoi(argv[1])];
}
uint64_t t = ClockCycles();
pid_t pid = fork();
if (pid == -1) perror("fork"), exit(EXIT_FAILURE);
if (pid == 0) exit(EXIT_SUCCESS);
if (pid > 0) {
waitpid(pid, NULL, WEXITED);
t = ClockCycles() - t;
}
if (blk != NULL) delete blk;
cout << "Fork time " << cycle2milisec(t)
<< " msec. [" << t << " cycles]" << endl; exit(EXIT_SUCCESS);
}
Эта программа сделана так, что может иметь один численный параметр: размер (в мегабайтах) блока условных данных (в нашем случае даже неинициализированных), принадлежащего адресному пространству процесса. (Функцию преобразования процессорных циклов в соответствующий миллисекундный интервал cycle2milisec() мы видели раньше, и поэтому в листинг она не включена.)
А теперь оценим временные затраты на создание клона процесса в зависимости от объема программы (мы сознательно использовали клонирование процесса вызовом fork(), а не загрузку spawn*() или exec*(), чтобы исключить из результата время загрузки образа процесса из файла):
# p2-1
fork time: 3.4333 msec. [1835593 cycles]
# p2-1 1
Fork time: 17.0706 msec [9126696 cycles]
# p2-1 2
Fork time: 31.5257 msec. [16855024 cycles]
# p2-1 5
Fork time: 70.7234 msec. [37811848 cycles]
# p2-1 20
Fork time: 264.042 msec. [141168680 cycles]
# p2-1 50
Fork time: 661.312 msec. [353566688 cycles]
# p2-1 100
Fork time: 1169.45 msec. [625241336 cycles]
Наблюдаются, во-первых, достаточно большие временные затраты на создание процесса (к этому мы еще вернемся), а во-вторых, близкая к линейной зависимость времени создания процесса от размера его образа в памяти и вариации этого времени на несколько порядков. Об этом уже говорилось при рассмотрении функции fork(): это следствие необходимости полного копирования образа адресного пространства родительского процесса во вновь создаваемое для дочернего процесса адресное пространство. При этом линейный рост времени копирования от размера образа процесса становится естественным (вот почему для образов таких задач при их построении посредством программы make в высшей степени целесообразно выполнить завершающую команду strip для уменьшения размера итогового образа задачи). Более того, это «высоко затратная» операция копирования, не в пример привычной функции memcpy(). Копирование производится между различными адресными пространствами обращением к средствам системы по принципу: скопировать N байт, начиная с адреса А адресного пространства Р, по адресу, начиная с А (тот же адрес!) адресного пространства С. В большинстве других ОС некоторое смягчение вносит использование техники COW (copy on write), но и этот эффект кажущийся (см. выше подробное обсуждение при описании функции fork()).
На результаты наших оценок очень существенное влияние оказывают процессы кэширования памяти, что можно легко увидеть, экспериментируя с приложением, но затраты (число процессорных тактов) на выполнение fork() будут оценены очень грубо:
T = 3000000 + Р * 6000
где Р — размер (в килобайтах) файла образа программы, в которой выполняется fork().
Теперь проведем столь же элементарный альтернативный тест (файл p2-2.cc) по созданию потока. (В случае потока время гораздо проще измерять и с более высокой точностью, но мы для сравнимости результатов почти текстуально сохраним предыдущий пример с включением в результат операторов завершения дочернего объекта, ожидания результата и т.д.)
Затраты на создание потока
void* threadfunc(void* data) { pthread_exit(NULL); }
int main(int argc, char *argv[]) {
uint64_t t = ClockCycles();
pthread_t tid;
pthread_create(&tid, NULL, threadfunc, NULL);
pthread_join(tid, NULL);
t = ClockCycles() - t;
cout << "Thread time, " << cycle2milisec(t) << " msec. [" << t <<
" cycles]" << endl;
exit(EXIT_SUCCESS);
}
На результаты этого теста (в отличие от предыдущего) уже достаточно существенно влияет приоритет, под которым выполняется задача, поэтому проделаем его с достаточно высоким приоритетом (29):
# nice -n-19 p2-2
Thread time: 0.147139 msec. [78667 cycles]
# nice -n-19 p2-1
Fork time: 2.5366 msec. [1356179 cycles]
Вот так… время порождения нового «пустого» процесса, даже минимального размера (размер исполняемого файла этого процесса чуть больше 4 Кбайт), почти в 20 раз больше затрат на создание потока! А для процессов большого объема эта разница может доходить до 3–4 порядков (см. результаты первого теста).
Далее рассмотрим сравнительную эффективность с другой стороны: будет ли диспетчеризация многочисленных потоков, принадлежащих одному процессу, эффективнее диспетчеризации такого же количества отдельных процессов? Для процессов задача текстуально выглядит так (файл p4-1.cc):
void workproc(int how = 1) {
const int nsingl = 1000, msingl = 30;
for (int j = 0; j < how; j++) // ... имитация вычислений
for (uint64_t i = 0; i < msingl; i++)
for (uint64_t k = 0; k < nsingl; k++)
k = (k + 1) - 1;
}
int main(int argc, char *argv[]) {
int numpar = 1;
if (argc > 1 && atoi(argv[1]) > 0)
numpar = atoi(argv[1]);
_clockperiod clcold;
ClockPeriod(CLOCK_REALTIME, NULL, &clcold, 0);
if (argc > 2 && atoi(argv[2]) > 0) {
_clockperiod clcnew = { atoi(argv[2]) * 1000, 0 };
ClockPeriod(CLOCK_REALTIME, &clcnew, &clcold, 0);
}
timespec interval;
sched_rr_get_interval(0, &interval);
cout << "Rescheduling interval = "
<< (double)interval.tv_nsec / 1000000 << " msec." << endl;
uint64_t t = ClockCycles();
for (int i = 0, i < numpar; i++) {
pid_t pid = fork();
if (pid == -1) perror("fork"), exit(EXIT_FAILURE);
if (pid == 0) {
workproc(1000);
exit(EXIT_SUCCESS);
}
}
for (int i = 0; i < numpar; i++) wait3(NULL, WEXITE0, NULL);
t = ClockCycles() - t;
cout << "Forks scheduling time" << cycle2milisec(t)
<< " msec [" << t << " cycles]" << endl;
ClockPeriod(CLOCK_REALTIME, &clcold, NULL, 0);
exit(EXIT_SUCCESS);
}
Имитатором активной вычислительной нагрузки программы является функция workproc(), отличительной особенностью которой является то, что она при активной (хоть и бессмысленной) загрузке процессора не делает на всем интервале своего выполнения никаких системных вызовов, которые могли бы привести к вытеснению выполняющего ее потока.
Первым параметром программы является количество процессов, на которые распределяется общий объем вычислений. Но самое главное: начнем управлять размером периода временного системного тика.
Примечание
По умолчанию системный тик (для QNX 6.2.1) равен 1 мсек., но в принципе его значение можно уменьшать функцией ClockPeriod() вплоть до 10 мксек. Кстати, в описании именно этой функции присутствует замечание о том, что «…период решедулирования равен 4 тикам, и это соотношение в системе нельзя изменить».
Второй параметр запуска программы (при его наличии) и определяет размер периода системного тика, выраженный в микросекундах. (В конце выполнения задач подобного рода, изменяющих размер системного тика, нужно обязательно принять меры к восстановлению его прежнего значения даже в случаях экстремального и аварийного завершения задачи!) Для повышения достоверности тестов величина размера интервала диспетчеризации контролируется независимым образом (вызовом sched_rr_get_interval()).
При распараллеливании вычислительного объема между потоками эквивалентный код (файл p4-2.cc) будет иметь вид (используется та же функция workproc()), которую мы повторно не показываем):
void* threadfunc(void* data) {
workproc(100);
pthread_exit(NULL);
}
int main(int argc, char *argv[]) {
int numpar = 1;
if (argc > 1 && atoi(argv[1]) > 0)
numpar = atoi(argv[1]);
pthread_t *tids = new pthread_t [numpar];
_clockperiod clcold;
ClockPeriod(CLOCK_REALTIME, NULL, &clcold, 0);
if (argc > 2 && atoi(argv[2]) > 0) {
_clockperiod clcnew = { atoi(argv[2]) * 1000, 0 };
ClockPeriod(CLOCK_REALTIME, &clcnew, &clcold, 0);
}
timespec interval;
sched_rr_get_interval(0, &interval);
cout << "Rescheduling interval = "
<< (double)interval.tv_nsec / 1000000 << " msec. " << endl;
uint64_t t = ClockCycles();
for (int i = 0; i < numpar; i++)
pthread_create(&tids[i], NULL, threadfunc, NULL);
for (int i = 0; i < numpar; i++)
pthread_join(tids[i], NULL);
t = ClockCycles() - t;
cout << "Threads scheduling time " << cycle2milisec(t)
<< " msec. [" << t << " cycles]" << endl;
ClockPeriod(CLOCK_REALTIME, &clcold, NULL, 0);
exit(EXIT_SUCCESS);
}
Наконец, для сравнительного анализа выполним тот же объем вычислительной работы в одиночном потоке, то есть в последовательной «классической» программе (файл p4-3.cc):
int main(int argc, char *argv[]) {
int numpar = 1;
if (argc > 1 && atoi(argv[1]) > 0)
numpar = atoi(argv[1]);
_clockperiod clcold;
ClockPeriod(CLOCK_REALTIME, NULL, &clcold, 0);
if (argc > 2 && atoi(argv[2]) > 0) {
_clockperiod clcnew = { atoi(argv[2]) * 1000, 0 };
ClockPeriod(CLOCK_REALTIME, &clcnew, &clcold, 0);
}
timespec interval;
sched_rr_get_interval(0, &interval);
cout << "Rescheduling interval = "
<< (double)interval.tv_nsec / 1000000. << " msec." << endl;
uint64_t t = ClockCycles();
workproc(1000 * numpar);
t = ClockCycles() - t;
cout << "Single scheduling time. " << cycle2milisec(t)
<< " msec. [" << t << " cycles]" << endl;
ClockPeriod(CLOCK_REALTIME, &clcold, NULL, 0);
exit(EXIT_SUCCESS);
}
Выполняем 3 полученных теста для различных значений периода системного тика (показано группами по 3 запуска) в таком порядке: одиночный процесс, параллельные потоки, параллельные процессы:
# nice -n-19 p4-3 10
Rescheduling interval = 3.99939 msec
Single scheduling time: 5928.8 msec [3169850746 cycles]
# nice -n-19 p4-2 10
Rescheduling interval = 3.99939 msec.
Threads scheduling time: 5919.82 msec. [3165049513 cycles]
# nice -n-19 p4-1 10
Rescheduling interval = 3.99939 msec.
Forks scheduling time: 5962.21 msec. [3187713371 cycles]
# nice -n-19 p4-3 10 50
Rescheduling interval = 0.197788 msec
Single scheduling time: 6427.33 msec. [3436394566 cycles]
# nice -n-19 p4-2 10 50
Rescheduling interval = 0.197788 msec.
Threads scheduling time: 6207.96 msec. [3319104030 cycles]
# nice -n-19 p4-1 10 50
Rescheduling interval = 0.197788 msec
Forks scheduling time 6029.23 msec. [3223548073 cycles]
# nice -n-19 p4-3 10 20
Rescheduling interval = 0.077104 msec.
Single scheduling time: 6745.37 msec. [3606433666 cycles]
# nice -n-19 p4-2 10 20
Rescheduling interval = 0.077104 msec
Threads scheduling time: 6762.69 msec [3615692975 cycles]
# nice -n-19 p4-1 10 20
Rescheduling interval = 0.077104 msec
Forks scheduling time: 6647.42 msec [3554062343 cycles]
# nice -n-19 p4-3 10 11
Rescheduling interval = 0.04358 msec
Single scheduling time. 7517.74 msec [4019381476 cycles]
# nice -n-19 p4-2 10 11
Rescheduling interval = 0.04358 msec
Threads scheduling time: 7638.89 msec. [4084155676 cycles]
# nice -n-19 p4-1 10 11
Rescheduling interval = 0.04358 msec.
Forks scheduling time: 7679 29 msec. [4105758575 cycles]
# nice -n-19 p4-3 10 10
Rescheduling interval = 0.036876 msec.
Single scheduling time: 7937.35 msec. [4243731124 cycles]
# nice -n-19 p4-2 10 10
Rescheduling interval = 0.036876 msec.
Threads scheduling time. 8136.42 msec. [4350159949 cycles]
# nice -n-19 p4-1 10 10
Rescheduling interval = 0.036876 msec
Forks scheduling time: 8172.35 msec [4369372230 cycles]
Результаты могут показаться достаточно неожиданными: во всех 3-х вариантах (в группах) это практически одни и те же цифры — различия затрат на выполнение и в едином последовательном потоке, и во многих параллельных процессах (как предельные случаи) не превышают 0,5–2%! Но результат есть результат, и его нужно как-то интерпретировать, ведь, как известно, «из песни слова не выкинешь».
Эти результаты позволяют (пусть грубо и оценочно) «разложить» затраты производительности между обслуживанием системного таймера (службы времени ОС) и диспетчеризацией. Еще раз обратимся к отдельным выборочным результатам:
# nice -n-19 p4-3 10
Rescheduling interval = 3.99939 msec.
Single scheduling time: 5928.8 msec. [3169850746 cycles]
To есть на протяжении «работы» было 5928,8/0,9998475 = 5929 прерываний от службы времени.
# nice -n-19 p4-3 10 10
Rescheduling interval = 0.036876 msec
Single scheduling time: 7937.35 msec. [4243731124 cycles]
На этот раз за счет уменьшения периода системного тика на 2 порядка на протяжении «работы» (того же объема полезной работы!) было уже 7937,35/0,009219 = 860977 событий диспетчеризации.
Поскольку объем работы программы, выполняемый в этих двух случаях, остается неизменным, то на обслуживание дополнительных 860 977 – 5929 = 855 048 системных тиков (совместно с 855 048/4 = 213 762 точками диспетчеризации) и потребовались те 4 243 731 124 – 3 169 850 746 = 1 073 880 378 дополнительных тактов процессора, или около 1256 тактов на один системный тик. Ранее мы уже получали оценки затрат собственно на переключение контекстов между процессами (617) и потоками (374), которые происходят каждый четвертый системный тик, то есть непосредственно переключение контекста «отъедает» в среднем 90–150 (? часть затрат переключения контекста) на каждый системный тик или, другими словами, не более 10% затрат на обслуживание службы системных часов.
Попытаемся осмыслить полученные результаты:
• Время переключения адресных пространств процессов, управляемых MMU аппаратно, в принципе должно быть продолжительнее времени переключения контекстов потоков и тем более восстановления контекста единого последовательного потока, но…
• …но объем работы по обслуживанию каждого системного тика (прерывания таймера) настолько превышает объем операций переключения контекстов (рис. 2.7), что это практически полностью нивелирует разницу, будь то приложение в виде многих автономных процессов, многопоточное приложение или приложение в виде единого последовательного потока.
Рис. 2.7. Эффекты, возникающие при принудительном изменении частоты системных часов
На рис. 2.7 показана последовательность тиков системных часов и связанная с нею последовательность актов диспетчеризации. При уменьшении периода наступления системных тиков (частоты аппаратных прерываний от системных часов) в силу фиксированных объемов операций, требуемых как для одних, так и для других действий, относительная доля времени, остающаяся для выполнения полезной работы, падает.
• И это будет выполняться не только для потоков, диспетчеризуемых с дисциплиной RR (вытесняемых по истечении бюджета времени выделенного им кванта), но и для потоков с любой дисциплиной диспетчеризации, в том числе и FIFO, когда выполняющийся поток (а значит, поток наивысшего приоритета в системе) вообще «не собирается» никому передавать управление.
• Для программиста-разработчика результаты этого теста позволяют сформулировать правило, возможно абсурдное с позиций элементарной (но поверхностной) логики: Распараллеливание задачи (если это возможно) на N ветвей (будь то использование потоков или процессов) практически не изменяет итоговое время ее выполнения.
Еще одним побочным результатом рассмотрения можно назвать следующее: эффективность диспетчеризации потоков (сохранения и переключения контекстов), принадлежащих одному процессу, ни в чем не превосходит эффективность диспетчеризации группы потоков, принадлежащих различным процессам. И в этом своем качестве — эффективности периода выполнения — потоки в своей «легковесности» ничем не превосходят автономные параллельные процессы.[25]
В завершение воспользуемся все теми же тестовыми приложениями для ответа на часто задаваемый вопрос: «Насколько эффективно ОС QNX поддерживает приложения, содержащие большое («слишком большое») количество потоков? Посмотрим, как это выглядит. Все выполнения мы делаем при минимально возможном значении системного тика, когда ОС существенно более «озабочена» своими внутренними процессами, нежели процессом вычислений:
# nice -n-19 p4-2 2 10
Rescheduling interval = 0.036876 msec.
Threads scheduling time: 1555.43 msec [831574415 cycles]
# nice -n-19 p4-2 20 10
Rescheduling interval = 0.036876 msec.
Threads scheduling time: 15642 msec. [8362674590 cycles]
# nice -n-19 p4-2 200 10
Rescheduling interval = 0.036876 msec
Threads scheduling time: 161112 msec. [86134950020 cycles]
Наблюдается очень хорошая линейная зависимость итогового времени от числа потоков (от 2 до 200). Таким образом, время выполнения работы в каждом из потоков практически не зависит от общего числа параллельно выполняющихся с ним потоков.
Повторим то же самое, но уже для случая параллельных процессов:
# nice -n-19 p4-1 2 10
Rescheduling interval = 0.036876 msec.
Forks scheduling time: 1622.87 msec [867633362 cycles]
# nice -n-19 p4-1 20 10
Rescheduling interval = 0.036876 msec.
Forks scheduling time: 16682.1 msec [8918698991 cycles]
# nice -n-19 p4-1 200 10
Rescheduling interval = 0.036876 msec
Forks scheduling time: 173398 msec. [92703484992 cycles]
Здесь наблюдается лишь незначительное увеличение крутизны линейной зависимости, что можно отнести к некоторым накладным расходам на поддержание достаточно большого числа записей о процессах в таблицах менеджера процессов, но величина этого эффекта также весьма малосущественна.
В итоге, в отношении «легковесности» потоков можно сказать следующее:
• При необходимости динамического создания параллельных ветвей в ходе выполнения программы (а это достаточно классический случай, например в разнообразных сетевых серверах, создающих ветвь обслуживания для каждого нового клиента) производительность приложения, функционирующего на основе потоков, может быть значительно выше (до нескольких порядков), а время реакции соответственно ниже.
• При статическом выполнении (фиксированном количестве параллельных ветвей в приложении) эффективность приложений, построенных на параллельных потоках или параллельных процессах, практически не отличается. Более того, эффективности таких приложений не отличаются и от классической последовательной организации приложения, работающего в одном потоке.
• Существует дополнительный фактор, обеспечивающий «легковесность» потоков в противовес процессам, — это легкость и эффективность их взаимодействия в едином адресном пространстве. В случае процессов для обеспечения таких взаимодействий возникает необходимость привлечения «тяжеловесных» механизмов IPC разнообразной природы (именованные и неименованные каналы, разделяемая память, обмен UNIX-сообщениями и другие). При рассмотрении обмена сообщениями QNX мы еще раз убедимся в том, что обмены и взаимодействия между процессами могут требовать весьма существенных процессорных ресурсов, а при обменах с интенсивным трафиком могут стать доминирующей компонентой, определяющей пределы реальной производительности системы.
Данный текст является ознакомительным фрагментом.