|
|
Пишет sadkov (![[info]](http://lj.rossia.org/img/userinfo.gif){kind=small} sadkov) |
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.
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.
Добавить комментарий:Sorry, this entry already has the maximum number of comments allowed.
