Просмотр полной версии : Многозадачность
captain cobalt
07.04.2005, 18:40
Краеугольный камень преткновения. ;)
Весьма интересно, какие будут ИМХи с обоснованиями. :)
честно говоря, я не думаю что многозадачность принесет какую-нибудь пользу
поэтому - 1
честно говоря, я не думаю что многозадачность принесет какую-нибудь пользу
поэтому - 1
У меня уже минимум в 2 интрах принесла пользу! =)
PS: Предлагаю тем, кто 'в теме', ещё устроить голосовалку по поводу оси (потому что ось!=многозадачность). =)
У меня уже минимум в 2 интрах принесла пользу! =)
давай не путать потоки и задачи
"мультипрограммируемость" когда имеют в виду возможность выполнять поочерёдно несколько задач/потоков/процессов.
Многозадачность - неопределённый термин, так обычно на обывательском языке называют мультипрограммируемость.
Насчёт тестирования я вот что скажу: автор теста пусть серьёзно подумает над вариантами ответа, это больше не на тест похоже, а на какую-то шараду (...мама нужна...).
И наперёд рекомендую убирать спецтермины (кооперативная и вытесняющая многозадачность), т.к. эти термины в разной литературе порой носят значительно отличающиеся значения.
Лучше было сделать тест такого плана: "за" и "против" мультипрограммируемости (многозадачности).
считаю такой вопрос... кхе, неуместным. во-первых нет никакой расшифровки что аффтар подразумевает под ответами, во-вторых какая разница как проголосует большинство если в этом деле разбирается менее десятка человек?
многозадачность нужна, реализуема и уже существует в простейшей форме. а как ее удобнее сделать на спектруме это уже вопрос не к большинству, а к реализаторам.
короче, "нашли" еще один миф спектрумизма - "Спектруму не нужна многозадачность".
АФТАР, ПИШЫ ЕЩО.
Уже сделал. Никакие стандартные схемы не пройдут - тут мне показалось наиболее оптимальным совмещение кооперативной и вытесняющей многозадачности.
Уже сделал. Никакие стандартные схемы не пройдут - тут мне показалось наиболее оптимальным совмещение кооперативной и вытесняющей многозадачности.
а ты знаешь что это уже давным-давно реализовано в "настоящих" ОС? %)
это функции sleep, alarm, wait (UNIX), sleep, yield (win). и никаких проблем нету
давай не путать потоки и задачи
Давай. Дай определение потоков и задач в моих интрах, учитывая отсутствие MMU.
PS: ...в который раз наблюдаю забавные вещи... На спек с линухов и виндов тянут всё подряд, без разбора. И форки, и файлы на память мапят, и потоки-задачи разделяют, и ехт3 хотят... А с пропуском прерываний не могут разобраться =)
И наперёд рекомендую убирать спецтермины (кооперативная и вытесняющая многозадачность), т.к. эти термины в разной литературе порой носят значительно отличающиеся значения.
Дык естественно, надо же думать своей головой! =)
Вытесняющая - это когда по прерываниям переключается контекст + приоритеты в свичере отрабатываются (кого сейчас запустить). При этом сами задачи пишутся как обычные программы которые делают обычным образом что им нужно, и даже могут не знать, когда и где их прерывали и насколько 'закопали' =)
Кооперативная - это когда каждая задача, проработав некоторый квант, должна ЯВНО отдать управление свичеру. Соответственно и свичер запустит её с ЯВНО определённого места. Это либо разбавление программы CALL _COOP_SWITCH вызовами, либо вообще писание всей программы в виде машины состояний с одной точкой входа. Каждый вызов она смотрит, какой кусочек надо сделать, делает его и возвращается.
Это имхо такие прозрачные понятия, что аппелировать к литературе просто как-то неприлично =)
Лучше было сделать тест такого плана: "за" и "против" мультипрограммируемости (многозадачности).
Почему - он же задан как 'какая * нужна в новой ОСИ?'. Вполне разумные варианты ответов.
Многозадачность НУЖНА однозначно. Иначе это будет не ОС, а какойто СуперКоммандер для запуска игрушек. А так можно скажем запустить игрушку и другую задачу, которая будет, скажем, отладчиком. Игрушка играется, отладчик в фоне чтото отслеживает. Или скажем читать текст и слушать музон в МП3 (если конечно аппаратный декодер прикрутить). Да мало ли ? ОС 21го века не должна быть однозадачной )
а ты знаешь что это уже давным-давно реализовано в "настоящих" ОС? %)
это функции sleep, alarm, wait (UNIX), sleep, yield (win). и никаких проблем нету
То же самое сделано в RTK. Единственное отличие - это то, что "в настоящих ОС" требуется аппаратная поддержка переключения контекста. У нас этого нет.
Давай. Дай определение потоков и задач в моих интрах, учитывая отсутствие MMU
каюсь. грешен. не имел счастья видеть твои интры... у уж тем более смотреть как там все устроено.
но подозреваю что потоки используют общую память и руляться специально заточенным под конкретную задачу менеджером.
если я правильно понял автора данного опроса, то имелось в виду многозадачность в оси. в таком контексте имеет смысл разделять понятия: поток и задача (независимо от того что эти понятия используются в существующих осях)
Единственное отличие - это то, что "в настоящих ОС" требуется аппаратная поддержка переключения контекста. У нас этого нет.
А что значит 'аппаратная поддержка переключения контекста'? Вон, в 68k и даже powerpc такого нет, но оси себя чувствуют отлично, в том числе и линухообразные! =)
каюсь. грешен. не имел счастья видеть твои интры... у уж тем более смотреть как там все устроено.
но подозреваю что потоки используют общую память и руляться специально заточенным под конкретную задачу менеджером.
Естественно заточенным под задачу (двузадачным даже), но а вот в амигаос тоже заточенным под задачу рулится (т.е. менеджером именно для амигаОС) и тоже память общая. Во многих вытесняющих РТОС тоже память общая. И что же - теперь все они всего лишь навсего многопоточные? Я и говорю - не надо с мерками линуха подходить ко всему. Линух - далеко не эталон. А кругозор полезно расширять хоть иногда. =)
если я правильно понял автора данного опроса, то имелось в виду многозадачность в оси. в таком контексте имеет смысл разделять понятия: поток и задача (независимо от того что эти понятия используются в существующих осях)
Каким образом и почему имеет смысл? Задача = указатель PC + стек + состояние остальных регистров + некая инфа для свичера (приоритеты и т.д.), чем это от потока отличается??
Про бритву Оккама что ли напомнить? Или не надо? =)
Каким образом и почему имеет смысл? Задача = указатель PC + стек + состояние остальных регистров + некая инфа для свичера (приоритеты и т.д.), чем это от потока отличается??
при переключении потоков тебе на надо беспокоится о сохранении/восстановлении блоков памяти. поскольку память у потоков общая и за ее сохранность отвечает только твоя задача.
в случае нескольких независимых задач в худшем случае придется память текущей задачи он новой прятать...
при переключении потоков тебе на надо беспокоится о сохранении/восстановлении блоков памяти. поскольку память у потоков общая и за ее сохранность отвечает только твоя задача.
в случае нескольких независимых задач в худшем случае придется память текущей задачи он новой прятать...
В линухе и в винде блоки памяти никто не сохраняет при переключении контекста (своп пока не рассматриваем). Просто переключают таблицы ММУ - если у каждого процесса своя виртуальная память.
В осях без защиты памяти опять же никто блоки памяти не копирует - все просто живут в общей памяти. Я ещё не встречал ни одной оси без защиты памяти, где при переключении контекста КОПИРУЕТСЯ вся память процесса. Такие вообще существуют? =) Подозреваю, что нет, но даже если и существуют, то это не означает, что такое же извращение надо на спеке делать.
В линухе и в винде блоки памяти никто не сохраняет при переключении контекста (своп пока не рассматриваем). Просто переключают таблицы ММУ - если у каждого процесса своя виртуальная память.
В осях без защиты памяти опять же никто блоки памяти не копирует - все просто живут в общей памяти. Я ещё не встречал ни одной оси без защиты памяти, где при переключении контекста КОПИРУЕТСЯ вся память процесса. Такие вообще существуют? =) Подозреваю, что нет, но даже если и существуют, то это не означает, что такое же извращение надо на спеке делать.
а кто здесь обсуждает линух или винду да еще с MMU?
само собой _ВСЮ_ память процесса никто копировать никуда не будет. но, согласно некоторым сообщениям в соседних ветках:
1. код процесса живет в странице -> переключаемся на новую
2. часть выделенной памяти живет в куче (ниже #c000) поэтому если новому процессу надо много памяти в куче, то надо спрятать RW блоки текущего процесса и вернуть/выделить блоки для нового.
само собой такой изврат будет не при каждом переключении задачи, но при недостатке памяти+отсуствии_защиты+1_п� �реключаемая_страница все равно придется делать копирование время от времени. другой вариант - более серьезные ограничения накладываемые на задачи (макс. объем нижней памяти)
само собой _ВСЮ_ память процесса никто копировать никуда не будет. но, согласно некоторым сообщениям в соседних ветках:
1. код процесса живет в странице -> переключаемся на новую
2. часть выделенной памяти живет в куче (ниже #c000) поэтому если новому процессу надо много памяти в куче, то надо спрятать RW блоки текущего процесса и вернуть/выделить блоки для нового.
само собой такой изврат будет не при каждом переключении задачи, но при недостатке памяти+отсуствии_защиты+1_п� �реключаемая_страница все равно придется делать копирование время от времени. другой вариант - более серьезные ограничения накладываемые на задачи (макс. объем нижней памяти)
Я вот думаю, будет ли оно в таком виде вообще юзабельным и даст ли какие преимущества в случае с тем же аль-асмом например? После предложений, что код в страницах, а данные будут лдириться время от времени, у меня закрадываются сильные сомнения... =)
После предложений, что код в страницах, а данные будут лдириться время от времени, у меня закрадываются сильные сомнения... =)
честно говоря у меня тоже :) но именно такие идеи продвигаются в соседних ветках. и именно на базе этого подхода предлагается строить многозадачную ось
зы: возможно я не до конца понял идеи GriV'а и Vitamin'а, но если что они меня поправят
честно говоря у меня тоже :) но именно такие идеи продвигаются в соседних ветках. и именно на базе этого подхода предлагается строить многозадачную ось
зы: возможно я не до конца понял идеи GriV'а и Vitamin'а, но если что они меня поправят
ща поправлю %)
представь себе такую ситуацию. приложение лежит в верхней странице и не имеет в общем случае права соваться в нижнюю память. оно имеет возможность резервировать куски памяти в его странице и обращаться к ним напрямую- тут ничего никуда перекидывать не надо. но в локальной странице особо не разбежишься- 64 сектора в лучшем случае. а достучаться до верхних страниц возможно только из нижней памяти. и тут есть три подхода.
первый. запрашивать систему на предоставление доступа к этой верхней памяти. система выделяет в нижней памяти буфер, _копирует_ туда кусок верхней памяти. приложение работает с буфером, через который происходит проекция (периодически буфер обновляется по мере изменения адресов).
второй. для операций последовательного просмотра вышеуказанный метод не очень подходит. поэтому система обязана предоставить некоторый стандартный набор функций для работы с верхней памятью, например копирование, очистка, пересылка. при этом она может использовать хоть дма, приложения это не касается.
третий. полулегальный %). в нижней памяти регистрируется библиотека или модуль, который может напрямую переключать страницы (с санкций системы, естесно) и работать с памятью. применимо для специфических функций, не реализованных системно.
так как довольно большая часть приложений не нуждается в расширенной памяти, копирование происходит не так часто как кажется
Пока ещё не ясно, каким приложениям может понадобиться быстрый доступ к верхней памяти (т.е. не через окно проекций), но я думаю что реализовать такие функции можно просто через стандартный монгопольный режим. Единственно, что будет отличать приложение, находящееся в монопольном режиме, от тех, что используют разделение процессорного времени - это положение.
В плане программирования, естественно, система не уходит в глубокий аут при запуске монопольного режима, просто отключаются некоторые из уже ненужных механизмов - многозадачность, окно менеджера и т.д.
Работа же со всеми остальными ресурсами производится всё равно через систему - никаких прямых выводов на контроллер FDD и т.п.
Corpsegrinder
20.04.2005, 12:59
Пока ещё не ясно, каким приложениям может понадобиться быстрый доступ к верхней памяти (т.е. не через окно проекций), но я думаю что реализовать такие функции можно просто через стандартный монгопольный режим.
На вскидку:
о AceEdit при редактировании 65 кб текста (вместо Ace Edit - вообще любой редактор, у которого планируется быстрая работа с блоками)
о BGE лбой версии, когда пытается например обработать скрин плугином...
да мало ли вообще всего? Но подход, когда часть функций регистрируются в системе как библиотека вполне мормально эту проблему решает.
На вскидку:
о AceEdit при редактировании 65 кб текста (вместо Ace Edit - вообще любой редактор, у которого планируется быстрая работа с блоками)
о BGE лбой версии, когда пытается например обработать скрин плугином...
да мало ли вообще всего? Но подход, когда часть функций регистрируются в системе как библиотека вполне мормально эту проблему решает.
Как раз в приведённых примерах монопольный режим меньше всего нужен... Он нужен для демок, больших игр, в общем для мультимеда контекста...
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot