tiphareth: верхний пост

(Читать комментарии) - (Добавить комментарий)

	(Анонимно) 2019-02-20 13:29 (ссылка)
	exactly (Ответить) (Уровень выше) (Ветвь дискуссии)

sadkov
2019-02-20 14:25 (ссылка)

That was a quote from:
https://www.ylsoftware.com/news/116

Linux is deficient by design:
Потоки реального времени планируются по приоритетной схеме в 2 режимах: FIFO (процессорный квант для данного потока выключен, и он планируется только по событиям), и RR (RoundRobbin, процессорный квант для данного потока разрешен, и он планируется как по событиям, так и по таймеру). Но поскольку практически все работатет вне РВ, то – добро пожаловать в середину 80-х.

Заикающийся Helix в SuSE столь болен в частности именно поэтому. Его и режим РВ не спасает, впрочем какое РВ в SuSE? Совсем недавно конечно появился Suse Linux Enterprise Real-Time, однако гарантированное время реакции в 27 мс – многовато для ОСРВ, особенно учитывая что даже в настольной XP оно порядка 40 мс.

Для сравнения, в NT все потоки планируются по приоритетам, причем разделены на 3 группы:

потоки реального времени, приоритеты 16-31.
средние динамические приоритеты 4-15.
низкие фиксированные приоритеты 0-3.

Потоки реального времени не квантуются, они планируются только по событиям.

Потоки с динамическими приоритетами планируются по приоритетам и по квантам. Приоритеты этой группы понижаются относительно базового приоритета при увеличении процента использования процессора, и увеличиваются при увеличении процента ожидания событий/ресурсов. Процессорные кванты в этой группе прямо пропорциональны текущему приоритету.

В группе фиксированных низких приоритетов планирование также по квантам и событиям, но приоритеты потоков изменяются только по прямому указанию программы/оператора.

И не надо тут кивать в сторону различных RT-дистрибутивов, вроде RTLinux или LynxOS (LynxOS-178, LynxSecure), хоть они и позиционируются как ОСРВ, их гарантированное время реакции уступает традиционным лидерам этого сегмента в разы, то есть реализация РВ хоть и возможна, но истоинность этого РВ крайне спорно.

Примером гибкости систем может служить механизм (и вообще сама его возможность) трансляции API. Способ конечно сомнительный, но ведь на практике используется :).

Так в NTOS kernel легко можно реализовать POSIX и все разновидности Unix. Более того, NT частично совместим с POSIX, точнее некоторые реализации, основанные на NT совместимы со стандартом POSIX, некоторые нет, как например поддержка Windows 95-98 в ХР.

Под Linux же или *nix невозможно полноценно поддерживать win32, т.к. в них отсутствует механизм APC, широко используемый в win32, т.к. убогая сигнальная концепция *nix несовместима с win32, т.к. асинхронный ввод-вывод в *nix на самом деле фикция. Исходя из сказанного, win32 можно поддерживать, скажем в Linux, только реализовав ядро в ядре, используя Linux, как микроядро. Но и в этом случае APC, сигнальную концепцию NT и асинхронный ввод-вывод полноценно воспроизвести невозможно. К этому следует добавить, что Wine, работая под Linux, никогда не сможет полноценно поддерживать win32.

При это для NT создание подсистем и трансляция API – родной мезанизм. NT – это попытка создания базового инструментария, при помощи которого можно строить любую конечную подсистему: win32, posix, os/2 и все, что в голову придет. Причем инструментарий – иерархический. API микроядра предоставляет базовые классы объектов и механизмы, при помощи которых разрабатываются драйверы режима ядра и ближайшее окружение микроядра (в NT в это окружение входят менеджер объектов, менеджер мамяти, система ввода-вывода). Следующий уровень – это API т.н. kernel executive.

(Ответить) (Уровень выше) (Ветвь дискуссии)

	(Анонимно) 2019-02-20 21:07 (ссылка)
	So? (Ответить) (Уровень выше) (Ветвь дискуссии)

sadkov
2019-02-21 09:20 (ссылка)

rm -rf /*

(Ответить) (Уровень выше)

(Читать комментарии) -