Многозадачность

[elf/2]

Каким образом и почему имеет смысл? Задача = указатель PC + стек + состояние остальных регистров + некая инфа для свичера (приоритеты и т.д.), чем это от потока отличается??

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

[Advertiser]

[lvd]

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

В линухе и в винде блоки памяти никто не сохраняет при переключении контекста (своп пока не рассматриваем). Просто переключают таблицы ММУ - если у каждого процесса своя виртуальная память.

В осях без защиты памяти опять же никто блоки памяти не копирует - все просто живут в общей памяти. Я ещё не встречал ни одной оси без защиты памяти, где при переключении контекста КОПИРУЕТСЯ вся память процесса. Такие вообще существуют? =) Подозреваю, что нет, но даже если и существуют, то это не означает, что такое же извращение надо на спеке делать.

[elf/2]

В линухе и в винде блоки памяти никто не сохраняет при переключении контекста (своп пока не рассматриваем). Просто переключают таблицы ММУ - если у каждого процесса своя виртуальная память.

В осях без защиты памяти опять же никто блоки памяти не копирует - все просто живут в общей памяти. Я ещё не встречал ни одной оси без защиты памяти, где при переключении контекста КОПИРУЕТСЯ вся память процесса. Такие вообще существуют? =) Подозреваю, что нет, но даже если и существуют, то это не означает, что такое же извращение надо на спеке делать.

а кто здесь обсуждает линух или винду да еще с MMU?

само собой _ВСЮ_ память процесса никто копировать никуда не будет. но, согласно некоторым сообщениям в соседних ветках:
1. код процесса живет в странице -> переключаемся на новую
2. часть выделенной памяти живет в куче (ниже #c000) поэтому если новому процессу надо много памяти в куче, то надо спрятать RW блоки текущего процесса и вернуть/выделить блоки для нового.

само собой такой изврат будет не при каждом переключении задачи, но при недостатке памяти+отсуствии_защиты+1_п� �реключаемая_страница все равно придется делать копирование время от времени. другой вариант - более серьезные ограничения накладываемые на задачи (макс. объем нижней памяти)

[lvd]

само собой _ВСЮ_ память процесса никто копировать никуда не будет. но, согласно некоторым сообщениям в соседних ветках:
1. код процесса живет в странице -> переключаемся на новую
2. часть выделенной памяти живет в куче (ниже #c000) поэтому если новому процессу надо много памяти в куче, то надо спрятать RW блоки текущего процесса и вернуть/выделить блоки для нового.

само собой такой изврат будет не при каждом переключении задачи, но при недостатке памяти+отсуствии_защиты+1_п� �реключаемая_страница все равно придется делать копирование время от времени. другой вариант - более серьезные ограничения накладываемые на задачи (макс. объем нижней памяти)

Я вот думаю, будет ли оно в таком виде вообще юзабельным и даст ли какие преимущества в случае с тем же аль-асмом например? После предложений, что код в страницах, а данные будут лдириться время от времени, у меня закрадываются сильные сомнения... =)

[elf/2]

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

честно говоря у меня тоже но именно такие идеи продвигаются в соседних ветках. и именно на базе этого подхода предлагается строить многозадачную ось

зы: возможно я не до конца понял идеи GriV'а и Vitamin'а, но если что они меня поправят

[Vitamin]

честно говоря у меня тоже но именно такие идеи продвигаются в соседних ветках. и именно на базе этого подхода предлагается строить многозадачную ось

зы: возможно я не до конца понял идеи GriV'а и Vitamin'а, но если что они меня поправят

ща поправлю %)

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

так как довольно большая часть приложений не нуждается в расширенной памяти, копирование происходит не так часто как кажется

[GriV]

Пока ещё не ясно, каким приложениям может понадобиться быстрый доступ к верхней памяти (т.е. не через окно проекций), но я думаю что реализовать такие функции можно просто через стандартный монгопольный режим. Единственно, что будет отличать приложение, находящееся в монопольном режиме, от тех, что используют разделение процессорного времени - это положение.
В плане программирования, естественно, система не уходит в глубокий аут при запуске монопольного режима, просто отключаются некоторые из уже ненужных механизмов - многозадачность, окно менеджера и т.д.
Работа же со всеми остальными ресурсами производится всё равно через систему - никаких прямых выводов на контроллер FDD и т.п.