OSDev

Фантом, Ёда, а как вы решаете проблему взаимных блокировок и критических секций в своих вытесняющих системах? Расскажите..

Ага, я так понимаю, в вашем понимании кооперативки ещё и защиты памяти нет? :)))
Какие именно проблемы взаимных блокировок и критических секций имеются ввиду? Дайте пример.
Кстати, я уже отметил, что упрощение синхронизации процессов - единственное преимущество кооперативки.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

В предложенной системе ещё ничего нет: ни защиты памяти, ни вытеснения.. Я её вынес на общее рассмотрение как мысленный эксперимент. И жду вашего участия в обсуждении. Взаимная блокировка: поток А пытается захватить мутекс, захваченный потоком Б и блокируется. Получает управление Б. Б пытается захватить мутекс, захваченный потоком А и блокируется. Оба потока теперь ожидают друг друга. Как поступить?

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


Это - классическая задача взаимной блокировки, но она не демонстрирует 100% преимущества кооперативки перед вытесняловкой. Здесь всё зависит от проектирования конкретных потоков. В принципе, можно спроектировать два взаимно блокирующихся процесса и в кооперативной многозадачности, хотя, согласен, вероятность такой ситуации меньше.
Для систем с вытеснением в случае нескольких потоков одного кода (включая разделяемый/библиотечный код) существуют специальные механизмы блокировки, при использовании которых взаимная блокировка исключается. Это механизм критических секций.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

Я не смешивал понятия кооперативной многозадачности и защиты памяти. Цитату в студию. В системах с защитой памяти переключение потоков обозначивает только переключение адресных пространств. О переключении контекста, увы, ничего не сказано.. На то она и кооперативная система, чтобы дать возможность потокам должное время для захвата мутекса или нахождения в критической секции, без переключения на другой поток. Именно поэтому они и не нужны, все эти мутексы;) Задача номер 2: Поток Б входит в критическую секцию ы2. Происходит смена потоков по прерыванию. Поток А, находясь в критической секции ы1, пытается войти в кс ы2 - блокируется. Управление получает Б. Б пытается войти в кс ы1 - взаимная блокировка. Учи мат.часть..

Ладно, не видите отличий КС от мьютекса, не можете внятно сформулировать, что такого сложного и долгоиграющего подразумевается под переключением потоков в системе с вытеснением в отличие от кооперативной системы с защитой памяти, - дело ваше. Не вижу смысла продолжать прения.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

Критическая секция - базовое понятие теории ОС. Оно обозначает такой участок кода/данных в котором между находящимися в нём потоками может возникнуть состояние "гонок". Во избежание "гонок" с понятием "критическая секция" стали связывать новое понятие - мутекс (взаимное исключение. Мутекс предпологает нахождение в критической секции нахождении не более одного потока, в отличие от семафора, допускающего разделение общего ресурса несколькими потоками. В случае использования несколькими потоками одинаковых ресурсов, возможна более высокоуровневая проблема - взаимная блокировка. Это связано со свойством мутекса блокировать потоки, пытающиеся получить доступ к занятой критической секции. Кооперативная система предпологает возможность нахождения потоков в критических секциях вплоть до выхода из них, без внезапной передачи управления. Это избавляет систему от механизма взаимного исключения (мутекса), что делает невозможным ситуацию взаимной блокировки. Поиск взаимных блокировок в вытесняющей системе является сложнейшей задачей в теории ОС.

Что касается реализации: в кооперативную систему всегда можно внести недостатки вытесняющей. А попробуй сдлелать вытесняющую систему с достоинствами кооперативной?!

В общем случае нет надобности использовать две параллельные критические секции. Но если говорить о параллельности, то и в кооперативной системе с ней придётся работать, чтобы использовать мощности многоядерного процессора для решения задачи.
Тренд развития процессоров идёт в сторону параллельных вычислений, а кооперативная многозадачность тут мало полезна всё-таки.

Химик, так ведь именно использование нескольких критических секций, в отсутствие взаимных блокировок и делает честь кооперативке. А многопроцессорные вычисления не содержат понятия вытеснения или невытеснения. Это истинная многозадачность. А кооперативка и вытесняловка - иллюзия многозадачности на одном камне. В многопроцессорных вычислениях не используют мутексы. Здесь популярны модели, на основе обмена сообщениями: синхронными, в CSP Хоара и асинхронными - модель акторов. Почитай о языке Оккам (CSP): там разделение процессов явно обозначено в тексте программы - никакого вытеснения. А сами по себе акторы вырасли из ооп и конечных автоматов - тоже кооперативные парадигмы. Вытеснение постепенно уходит в прошлое, как "универсальная альтернатива" однопроцессорной псевдомногозадачности. Если есть желание, можно обсудить и распределённые вычисления. Для меня это интересная тема. Но боюсь и они остануться недооцененными в свете "вытесняющих взглядов".