Страница 1 из 2

Техническая реализация многозадачности

Добавлено: 03 дек 2005, 23:46
Victor Gr.
В случае однозадачной ОС программа монопольно владеет всеми ресурсами ПК: микропроцессором, кэшами двух уровней, оперативной памятью.
В этом случае, скорость программы прямо пропорциональна качеству алгоритма и кода, а также производительности всех узлов ПК.

В условиях многозадачной ОС, программа уже не владеет ПК все время своего выполнения, а вынуждена делить его с ПО, работающим одновременно с ней.

Известно, что в еденицу времени один процессор не может выполнять две задачи одновременно, значит иллюзию многозадачности можно создать только быстро-быстро переключаясь между задачами.

По моим представлениям, программа, выполняющаяся в однозадачной среде, выйграет по скорости аналогичную в многозадачной среде, при прочих равных. По крайней мере не будет потерь на переключение задач.

Интересует меня именно техническая реализация этих переключений. Что делает ОС во время переключения между процессами? Что происходит с кэшем, памятью... И сколько времени на это уходит?

Добавлено: 04 дек 2005, 00:23
passer-by
могу кинуть на мыло почитать Understanding the Linux 2.6.8.1 CPU Scheduler (на английском, с примерами сишной кодяры из сырцов ядра), но ты плиз пообещай больше не постить всякую ересь касательно АВС (архитектуры вычислительных систем)

Добавлено: 04 дек 2005, 00:26
Victor Gr.
passer-by, почему ерунду? почему не постить?

Простите, если вам это не интересно - больше не буду.

Добавлено: 04 дек 2005, 00:48
Hermit
Для x86 ключевые слова GDT, LDT, TR.
Начальные сведения можно найти здесь: http://www.zsu.zp.ua/lab/MathDep/ApMath ... orl29.html

Добавлено: 04 дек 2005, 01:48
Victor Gr.
Большое спасибо за наводку!

Ещё мне подсказали "Современные ОС" Таненбаума. Буду искать...

Добавлено: 02 фев 2006, 22:17
dimm_coder
вопрос как всегда в компромисе между производительностью и какой-то другой функциональностью - в данном случае многозадачность. на то она и операционная система _общего_ назначения что она должна быть относительна справедлива ко все - как задачам ориентированным на потребление процесса (просто вычисления) так и интрерактивным (здесь важно время отклика).

естественно, если есть два вычисления которые не блокируются и независимы, то например эффективнее выполнить их одно за одним а не в параллельных потоках (если это одно-процессорная машина). а еще лучше на какой-нибудь пакетной ОС.

в общем, интересно то интересно. но в принципе эти вопросы и их решения абсолютно не новы и им уже добрых 4 десятка лет :) т.е. в интернете достаточно информации по данному поводу.

книга Вахалии UNIX Internals очень хороша.

Добавлено: 02 фев 2006, 23:25
Victor Gr.
dimm_coder, скажите, где вы работаете?)
Откуда такие подробные и ценные знания по данным вопросам?

Добавлено: 03 фев 2006, 05:24
red f0x
dimm_coder, пакетная ОС? Ммм, что это? То что вопросы не новы - положим так, а вот их техническая реализация на конкретной платформе (x86-IA32) - не поверю. Ну не может быть ЦПУ i386 уже 40 лет :)
Victor Gr., ну а Вам совершенно правильно дали направление в сторону TR, TSS, IDT, LDT и проч. На Intel и им подобных многозадачность реализуется на аппаратном уровне с помощью этих вещей, а на уровне ОС - тут уж могут быть, ессесно, расхождения, как эти особенности архитектуры используются... Думаю, больше всего про "аппаратную многозадачность" будет в документации фирмы-производителя (Intel, то бишь - остальными можно пренебречь, ИМХО) - т.е. в IA-32 Intel Architecture reference, к-я доступна на интеловском ресурсе.
А зачем Вам енто? Вопросец-то и вправду немного странный и крамольный или может просто сформулирован не так? :) Просто, на самом деле, глупо было бы отказаться от возможностей платформы - типа купи тачку только для того, чтобы пыль с неё по выходным стирать :)

Добавлено: 03 фев 2006, 06:52
red f0x
Немного конкретнее:
В процессорах i386+ есть такое понятие, как TSS - сегмент состояния задачи - что в нём хранится, думаю, ясно из названия. На каждую задачу есть свой
TSS. Переход на другую задачу осуществляется через jmp или call сегмента состояния или т.н. вентиля задачи (см. GDT, LDT). Переход может осуществляться по
аппаратным прерываниям, если соответственно настроена таблица дескрипторов прерываний (IDT). Регистр TR содержит базовый адрес и лимит по селектору текущего TSS. Кэши ответственны за результаты трансляции адресов, если мне не изменяет склероз. На прямую программно они не могут быть модифицированы - только полностью сброшены. Так вот кэшами управляет непосредственно процессор (MMU?), поэтому потери времени при переключении минимальны. Тем более, если опять же моя память мне с кем-то не изменяет, то кэши не сбрасываются при переключении задачи. Эта тема занадта обширна - тут в общем стоило бы полностью перелопатить весь защищённый режим - так что, если надо, ориентируйтесь на это...
Что касается ядра - то там уже многозадачность обеспечивает планировщик - узнать о линуксовом планировщике Вы можете и из той же Understanding the Linux kernel.

Добавлено: 03 фев 2006, 09:33
Llama
red f0x, пакетная ОС - ОС которая выполняет задпания по одному. Задания группируются в пакеты которые поступаю на выполнение. КПД максимальный. Примеры - см. IBM DOS/VS или IBM MVS или советские пизженые поделки на ту же тему..

Добавлено: 03 фев 2006, 10:12
red f0x
Llama, мдя - дикие зверюги, сколько живу а с такими ещё не приходилось иметь дело...:)

Добавлено: 03 фев 2006, 12:21
dimm_coder
Современные версии Linux не используют аппаратную поддержку
переключений контекстов предлагаемую x86 архитектурой, а именно
переключение между TSS задач с помощью jmp. Отдельный процесс
не имеет отдельного TSS. В общем случае поддерживается один TSS
на процессор и во время переключений контекстов ОС обновляет
некоторые его поля, чтобы они соответствовали текущему процессу.

Упомянутая Understanding the Linux Kernel может внести большую ясность.

...

если имеются ввиду кэши процессора (1-го и 2-го уровня) то при переключении контекстов с ними ничего не происходит (конечно во время работы второй задачи может произойти перезапись участков используемых первой - т.е. некоторые регионы памяти которые были в кэше когда выполнялась первая задача, уже там не будут когда она получит процессор назад).

другое дело TLB (Thread Lookaside Buffer) предназначение которого ускорить трансляцию виртуальных адресов (каждый процесс имеет отдельное виртуальное адресное пространство) в физические. В виду различия виртуальных адресных пространств (если это не переключение между "потоками") содержимое TLB оказывается, в общем случае, некорректным для нового процесса и вот его
содержимое сбрасывается при переключении контекстов.

для дополнительной информации искать в сторону MMU (Memory Managment Unit) и уже упомянутому TLB.

Добавлено: 04 фев 2006, 02:57
red f0x
dimm_coder, Во, оно! :)
Ну короче - я думаю, теперича у вопрошавшего масса инфы для старта в нужном направлении и с нужной траекторией :D

Добавлено: 04 фев 2006, 10:39
dimm_coder
Victor Gr. писал(а):dimm_coder, скажите, где вы работаете?)
Откуда такие подробные и ценные знания по данным вопросам?
таки нигде, безработный я на данный момент.

"подробного" это относительное понятие да в принципе как и "ценные".
хотя, в последнем случае, это всетаки не кирпичи :)
то что я говорил всего-лишь информация достаточно общего плана, которую большей частью без особого труда можно найти в любой книге по теории ОС.

Добавлено: 04 фев 2006, 15:57
mend0za
dimm_coder: рад что ты вернулся