OSDev

В системах с вытеснением проблему взаимных блокирок можно решить отказавшись от мутексов в пользу обмена сообщениями. Это самый грамотный подход. Он реализован в концепции микроядра. Различают синхронный обмен (рандеву), когда и приёмник и отправитель должны быть готовы к обмену, и асинхронный когда нет необходимости в рандеву, т.к. сообщения буферизируются. Асинхронный обмен был в микроядре первого поколения - Mach. О проблемах этого микроядра можно почитать отдельно. Микроядра второго поколения используют только синхронный обмен: Minix, L4, QNX/Neutrino... Но синхронный обмен требует частого переключения контекстов. В кооперативной системе сообщения нужно посылать реже (только для обмена данными, синхронизация для работы в кс не нужна), а переключение задач происходит на порядок быстрее. У кого какие мысли?

И вообще: почему у меня начинает сладываться впечатление, что Химик единственный человек на этом форуме, который адекватно понимает, о чём речь?

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

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

SII, на правах администратора давно бы создал раздел "Для новичков" или "Базовые понятия". Только так, чтобы только ты мог изменения вносить в статьи. Мог бы привести список популярной литературы, ссылки полезные. Базовые термины теории ОС и т.д. А то либо люди не понимают о чём говорят, либо говорят об одном и том же, но на разных языках..

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

Т.е. ты имеешь ввиду случаи с единой для нескольких камней памятью? Согласен, тут не прокатит. Только обмен сообщениями, думаю, спасёт. Просто мне сложно представить "критическую секцию" между машинами без общей памяти. Например, по сети соединённых, или ещё как нибудь. Тут по сути тот же обмен сообщениями, разницы особой нет. А в системах с общей памятью вообще "жесть" алгоритмы: всякие транзакции, уровни консистентности и т.п. Специально поищу инфу на эту тему. Интересно стало, как там с "критическими секциями"?..

"О, сколько нам открытий чудных!.."
Многопроцессорные системы с архитектурой shared memory (к коим относится вся линейка PC/AT) НЕВОЗМОЖНО организовать без мьютексов. Обмен сообщениями в многопроцессорной системе - это только логическая надстройка над мьютексами, облегчающая программирование.
Что касается критических секций,... чувствую я, ты с ними не работал и рассуждаешь сугубо абстрактно в духе "а вот если взять в руки пассатижи, то можно защемить себе палец". У меня сегодня благостное настроение, поэтому выкрою пару минут, чтобы разъяснить тебе. Конечно любой инструмент можно извратить, использовать не по назначению или не правильно. Но тогда нельзя говорить, что инструмент плохой.
Критическими секциями пользуются так. Вместо того, чтобы блокировать доступ порознь к горстке разных данных, весь код, обрабатывающий эти данные, инкапсулируют в одну функцию. В функции перед началом работы с данными открывают КС, после того, как обработают все данные, как единое целое, закрывают КС и возвращают управление. Если два потока, в т.ч. и на физически разных процессорах/ядрах одновременно вызовут функцию, то сначала отработает одна, потом в критическую секцию войдёт другая. Пересечение [разных] КС, хотя теоретически возможно, на практике не рекомендуется. Точно также, как есть оператор goto, но если пользуешься им, то сам отвечаешь за все последствия и не кричишь, что ОС/язык/процессор неправильные.
При описанном подходе критические секции гарантированно избавляют от взаимной блокировки в т.ч. и в многопроцессорных системах с общей памятью.


Если сто раз повторить "на порядок быстрей", то наверно, все безоговорочно поверят )))


На этом сайте уже есть wiki. Есть время и силы - вноси изменения. :)
(SII, присмотри, чтобы он там лишнего не внёс :)


Ссылок полно в соответствующей теме форума.


Базовые термины очень хорошо разъяснены в Википедии.

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

Всё нормально. Достаточно применения префикса блокировки (lock), чтобы выполнять атомарные действия с переменными в памяти.

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