2all: Неверно. Точнее верно, если задача работает сама по себе секунд 10, потом вдруг решает ни с того ни с сего 'отдаться'. А если она завязана на прерывания и ждёт какого-то события оттуда, а потом что-то посчитает и снова баиньки до следующей эксгумации =), то вероятность пропуска в таком случае увеличивается.Сообщение от Vitamin
Угу, поясни. КТО у тебя вызывает свичер с контекстом какой-то свичиваемой им задачи в регистрах?
Чтобы переключить задачу, надо её прервать. Это можно сделать только прерыванием. Следовательно, именно в прерывании надо менять контекст.
Не может такого быть. Переключать контекст надо именно в прерывании. У тебя все равно предполагается, что обработчик прерывания отдает управление переключателю контекста. А если нет - тогда просьба пояснить, когда и как он исполняется.Переключатель контекста и обработчик прерываний есть две совершенно различные процедуры/подпрограммы.
Еще попробуй посчитать потери на планирование потоков при таком подходе. Я перед тем, как написать RTK, посчитал. Классический метод при адекватном написании теряет до тысячи тактов на планирование потоков. Это роскошь уже недопустимая...
Ведём спокойную дискуссию называется....
Сигнал прихода прерывания ты можешь использовать как сигнал окончания псевдокванта времени (1/50 секунды), но вообще-то говоря ты его используешь именно как прерывание.
Если ты прервал работу программы - так всё равно все данные (регистры, флаги, стек) сохранены в стеке (или в памяти, это не так важно) и потом можно восстановить их для перехода (по необходимости, если такая есть) к переключателю контекста.
Если же уже запущен переключатель контекста, то просто возвращается выполнение и всё, мне не ясно про что ты вообще говоришь...
Задача прерывается самим прерыванием только в двух случаях
1. В случае, если вдруг оказалось что программа не поддерживает квантование своего времени - т.е. она не использует принципы и соглашения невытесняющей многозадачности, в результате после прихода прерывания этот факт будет отслежен (после того как отработает обработчик прерывания и передаст управление на диспетчер потоков). А принципы и соглашения следующие: если есть возможность выполнив какую то элементарную операцию отдать управление системе, то это надо делать; элементарная операция является таковой если она длится менее 5 мсек.
2. Программа следует указанным правилам и соглашениям, но просто она попала на границу псевдокванта. В таком случае всё равно происходит передача управления на диспетчер потоков и никаких последствий.
И вообще, что за "упрощизм" в моде у программистов?
Предлагается два подхода:
1. "Упрощенческий". Обработчик прерываний и диспетчер потоков (читай: переключатель контекстов потоков) совмешены в одно единое целое. Тогда имеем все указанные проблемы и продолжаем дальше заниматься "упрощизмом".
2. Классический подход. Обработчик прерываний и диспетчер потоков разные программы, взаимодействующие по классическим правилам. В этом случае никаких проблем нет.
Дело в том, что ты сразу себе должен отдавать отчёт в невозможности применения стандартных методов вытесняющей многозадачности. Просто нет поддержки со стороны железа и всё. Поэтому уже на одном этом основании предполагается, что используется именно невытесняющая многозадачность. Правила невытеснящей многозадачности ты знаешь, сверху они в упрощённой форме озвучены, повторяться нет смысла.
А что нужна именно невытесняющая (кооперативная) многозадачность (по крайней мере сейчаз) мне кажется очевидным: стандартная раскладка, в которой сейчаз хочется увидеть многозадачность такова: имеется обработчик клавиатуры (кооперативен), имеется обработчик мышки (кооперативен), имеется плеер AY-музона (тоже кооперативен), имеется текстовый редактор (или какой либо другой редактор, тоже вообще то кооперативен), имеются 1,2, и т.д. потоков, которые выполняются в фоне (вычисления, компиляция, форматирование текста, анализ загруженных данных и т.д.; некооперативны).
Отстаётся единственный вопрос, как отслеживать "зажравшиеся" потоки/задачи/процессы (они обозначены как некооперативные), которые не придерживаются правил кооперации в системе. Вот для этого и необходим обработчик прерываний (и не только для этого на самом деле, но это уже не для спектрума). Обработчик прерываний будет давать информацию (а т.к. он имеет более высокий приоритет, то он и будет исполняться раньше) для диспетчера потоков о том, что какой-то поток нарушает требования. А дальше уже диспетчер потоков решает как поступать с "заблудшим" потоком.
Чем мерять собираешься?
Это с какого он 'классическим' стал? =)
Проблем нет, так как ты по сути предложил откладывать прерывания, когда их можно пропустить. Все красивые и сказанные с гордым выражением слова не изменяют сути =)
а что мешает пойти на компромисс?
делаем обработчик прерываний, внутри у него стоит диспетчер (упрощенная схема), но также имеется и некая система обработки состояния системы. в зависимости от флагов этот кусок кода может выступать и как диспетчер задач (разрешено вытеснение) и как обработчик прерываний (вытеснение не разрешено, но это чревато рассинхронизацией процессов реального времени).
а процедура пропуска кванта по сути дела представляет собой выполнение двух действий: перевод текущего процесса в состояние сна и вызов диспетчера. а так как у нас на диспетчер завязаны синхропотоки, то необходимо это дело слегка уложнить
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием