>Отлично ! А я боялся, что так останусь для вас болтуном-идиотом. И
>теперь переносимся в ОС с микроядром, где количество и размер таких
>критических секций очень мало так как взаимодействие между частями ОС выполняются
>на более высоком уровне и есть другие, более подходящие для параллельного
>выполнения механизмы IPC. ты будешь удивлен, но эти "другие, более подходящие для параллельного выполнения механизмы IPC" будут требовать НЕ МЕНЬШЕ локов для обеспечения ТОГО же уровня функционала/гибкости/скорости_реакции_системы/производительности :)
чисто по логике ;)
ну а если логика страдает и ты веришь в эти светлые и непорочные "механизмы IPC" (которыми, кстати, являюццо очередя сообдещий), то смотри.
Если будет одна очередь сообщений не-взирая сколько процов в системе - то будет затык
ввиду того, что все 3 проца _могут_ быть в состоянии ожидания пока один работает с очередью (добавляет/удаляет/читает сообщение). Локов мало, но потеряна скорость реакции.
Чтоб поправить ситуацию - делаем, например, 2 очереди сообщений: одна общая, допустим, а другая, допустим, для сетевых операций. И тут уже развязка будет получше: посылка пакета и системный вызов fork() уже могут друг другу не мешать. Но все равно, до оригинальных параметров системы далеко. И мы создаем еще и еще очередя... А на каждую нужен свой лок...
В результате - будет просто микроядро :), но с тем же количеством локов (или большим даже,
ввиду заведомо большего числа процессов в системе).
Так что... как бы твоя гипотеза не доказывала бы обратное ;) Что в микроядре БОЛЬШЕ локов, чем в монолите. (или мы теряем один/больше параметров ядра)
|
