реал тайм осы

П.10. - это тоже из технических, не "академических" требований: RTOS должна иметь адекватные (realtime) средства сетевого взаимодействия.

Об чём речь? Что у нас есть практически во всех OS общего применения? Правильно - TCP/IP (IPX/SPX - это славная, но практически умершая технология, и - не считать же серьёзной сетевой технологией "одоробло" NETBEUI от MS?).

TCP/IP по ряду причин не годится для realtime & embedded приложений. Т.е., очень даже годится, и даже крайне желателен, например, для управления извне (зашёл по telnet или ssh - и чудишь как у себя дома) - но не годится для гарантированной доставки данных. TCP/IP разрабатывался и оптимизировался для WAN, а не для LAN, и главная его характеристика "живучесть", но никак не "гарантированность". Вот, например, существует общее заблуждение, что TCP ("протокол гарантированной доставки", про UDP я даже не говорю) - может обнаружить обрыв канала... - не может: будете сидеть в своём блокирующем read() до посинения ;-)... И многое другое, причин много, сейчас не об этом - если кому будет интересно, я перечислю отдельно.

Тот же QNX - имеет в своём составе развитую сетевую подсистему Qnet - "гарантированного реагирования", которая, кроме того - плотно и органично интегрируется с работой полностью автономного стека TCP/IP.

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

Вы еще будете меня за многозадачность агитировать ;-)
Тем не менее - есть. Вот даже у меня рядом стоит - ящик для радиоканала - так внутри дос.

Первоначально опубликовано Olej И ещё, к развеиванию иллюзий однозадачности у автоматчиков (а она - ой как есть!) - если у вас есть хоть одно (!) ассинхронное событие внешнего мира - прерывание: у вас уже есть классическая многозадачность! И хорошо, если она обслуживается такими же классическими API OS, и очень плохо - если "самопалками" от непонимания, что перед нами таже общая проблема ("вот кинжал: он хорош для того, у кого он есть, и плох - для того, у кого его нет"(с) ;-)).

"Автоматчики" как вы выражаетесь поступают элементарно: используют цикл опроса на манер поллинга с такой частотой, что никакой асинхронности нету. Вон у меня в DSP - все укладывается в 2-3 микросекунды.

Первоначально опубликовано Olej А вот на предмет: "псевдомногозадачный режим в стиле DOS" - акститесь! Я столько руками переделал этих TSR, зубы на этом проел... много могу порасказать - о том, например, что почти все эксплуатируемые TSR были сделаны некорректно, а потом говорят "виснет, виснет"... Переключение в TSR корректно только в том случае, когда вы сохраняете контекст задачи - в DOS это PSP - первый сектор задачи, да и это ещё не всё... Теперь представьте: для переключения на выполнение 3-х команд в TSR ... начинаем сохранять 256 байт (куда? может на диск ;-)? или в область памяти - так её ещё выделить нужно, динамически, и лучше по принципу стека - этот TSR может другой прервать!?)... а выполнив - вернуть братно.

Заметьте - я про TSR ничего не говорил. Просто все сделано через большой цикл с кучей switch'ей, callback-ов, тайм-аутов и нарезкой данных на куски.

Первоначально опубликовано Olej Ещё будем об realtime и предсказуемости поведения говорить в этом случае?

Конечно. squid работает на многих платформах и под большой нагрузкой. С предсказуемым поведением. И с такой архаичной внутренней организацией.

Первоначально опубликовано Olej Первоначально опубликовано evgen Критические секции тоже есть и используются. Чем оно избыточное - непонятно. А потому, что: - в POSIX его нет - не нужно, и так всего хватает; - где мютексы есть - так критическую секцию создать труда не составляет, кто понимает...

На ассемблере тоже можно все что угодно изобразить - однако ж. И эээ.. навскидку - с мутексами будет тормознее. Намного.

Первоначально опубликовано evgen Вы еще будете меня за многозадачность агитировать ;-) Тем не менее - есть. Вот даже у меня рядом стоит - ящик для радиоканала - так внутри дос.

Почти как говорил М.Жванецкий: что ящик стоит - верю, что там внутри дос - верю, а вот что однозадачность - не верю - отныне и во веки веков, аминь ;-).

Чисто однозадачным процессом можно считать только что-то из численных вычислений - решение какого-то квадратного уравнения, что ли...

Как только у вас любое IRQ - всё, это поехала новая, параллельная ветка... В том случае, если вы аккуратничаете, сохраняете 2-3 регистра (даже не трогая сегментных, возможно), не сохраняя контекста прерванной задачи - так это только из-за элементарной простоы действий, выполняемых в обработчике (кстати, и эта привычка элементарных действий в обработчике - это "обратным концом" привычка, выработанная неприятностями ;-)).

Первоначально опубликовано evgen используют цикл опроса на манер поллинга с такой частотой, что никакой асинхронности нету.

Активноый опрос со 100% загрузкой процессора? Хорошее решение...

Первоначально опубликовано evgen Заметьте - я про TSR ничего не говорил. Просто все сделано через большой цикл с кучей switch'ей, callback-ов, тайм-аутов и нарезкой данных на куски.

TSR - это только название, и всего.
Но всё происходящее происходит точно также: calback-и (по сетевым событиям, ведь вы об squid говорите, если я понял?) - прерывания по сетевым событиям, тайм-ауты - прерывания от системного таймера, а на них обработчики, обработчики, обработчики... А на них - сохранение контекста, или без - но это "если повезёт"...

Первоначально опубликовано evgen Конечно. squid работает на многих платформах и под большой нагрузкой. С предсказуемым поведением. И с такой архаичной внутренней организацией.

Под многими - я видел, знаю...
Под однозадачной дос - не видел..., но может пропустил чего.
Но считать squid как образец ... "с предсказуемым поведением" в смысле realtime? Нет, право, батенька, это уж слишком. Да если он заснёт над вашим запросом на лишних 5 минут - так вы и не заметите... даже на 15 минут - тоже не успеете идти на разборки с администратором...

Первоначально опубликовано Olej Первоначально опубликовано evgen Вы еще будете меня за многозадачность агитировать ;-) Тем не менее - есть. Вот даже у меня рядом стоит - ящик для радиоканала - так внутри дос. Почти как говорил М.Жванецкий: что ящик стоит - верю, что там внутри дос - верю, а вот что однозадачность - не верю - отныне и во веки веков, аминь ;-). Чисто однозадачным процессом можно считать только что-то из численных вычислений - решение какого-то квадратного уравнения, что ли... Как только у вас любое IRQ - всё, это поехала новая, параллельная ветка... В том случае, если вы аккуратничаете, сохраняете 2-3 регистра (даже не трогая сегментных, возможно), не сохраняя контекста прерванной задачи - так это только из-за элементарной простоы действий, выполняемых в обработчике (кстати, и эта привычка элементарных действий в обработчике - это "обратным концом" привычка, выработанная неприятностями ;-)).

В ящике для радиоканала - наверное есть прерывания, а в остальном - можно и без них с тупым поллингом

Первоначально опубликовано Olej Первоначально опубликовано evgen используют цикл опроса на манер поллинга с такой частотой, что никакой асинхронности нету. Активноый опрос со 100% загрузкой процессора? Хорошее решение...

DSP или PICу - это по барабану, у них все время 100% загрузка, кроме режимов сна

Первоначально опубликовано Olej Первоначально опубликовано evgen Заметьте - я про TSR ничего не говорил. Просто все сделано через большой цикл с кучей switch'ей, callback-ов, тайм-аутов и нарезкой данных на куски. TSR - это только название, и всего. Но всё происходящее происходит точно также: calback-и (по сетевым событиям, ведь вы об squid говорите, если я понял?) - прерывания по сетевым событиям, тайм-ауты - прерывания от системного таймера, а на них обработчики, обработчики, обработчики... А на них - сохранение контекста, или без - но это "если повезёт"...

TSR - это еще и куча ограничений...
А в сквиде все сетевые события проверяются в одном месте - через select или poll - и далее только обработчики и никаких таких прерываний. Цикл опроса длится где-то 100-200 мс, а все остальное сидит в буферах TCP стека...

Первоначально опубликовано Olej Первоначально опубликовано evgen Конечно. squid работает на многих платформах и под большой нагрузкой. С предсказуемым поведением. И с такой архаичной внутренней организацией. Под многими - я видел, знаю... Под однозадачной дос - не видел..., но может пропустил чего. Но считать squid как образец ... "с предсказуемым поведением" в смысле realtime? Нет, право, батенька, это уж слишком. Да если он заснёт над вашим запросом на лишних 5 минут - так вы и не заметите... даже на 15 минут - тоже не успеете идти на разборки с администратором...

;-) В дос оно не влезет по размеру - разве что с экстендером.
А на предмет заснет-не заснет - тестируют его в хвост и гриву - не засыпает. Хотя неприятности с ним случаются при потере связи - но это уже из другой области

Первоначально опубликовано Olej П.4. - его даже не называют часто (а зря), это сильно связано с приоритетами выше: "RTOS должна иметь эффективные и управляемые процедуры диспетчеризации". Очень интересный пункт - об одном ём можно книжку написать ;-). POSIX 1003b (стандарт POSIX в части realrime возможностей, я на него буду много ссылаться) определяет 4 дисциплины диспетчеризации: FIFI, RR (round-robin), adaptive, sporsdic. Разработчикам OS общего применения часто даже не приходит на ум иметь одновременно несколько дисциплин диспетчеризации - они ищут "лучшую"... - в Linux - чистая round-robin (на уровне, фактически, процессов! - мы ещё к этому вернёмся); - в Windows... это отдельная песня: в 3.1/3.11 было то, что MS "изобрели" как "кооперативная многозадачность" - у всех остальных нормальных людей это FIFO. В 95/NT/... - это "вытесняющая многозадачность", т.е. то, что у остальных RR, но у них ещё идёт "изобретательство" по изменению (снижению) приоритета выполняющегося процесса - т.е. это типичая adaptive. О том, на уровне чего (процессов или потока) идёт диспетчеризация в Win32 судить трудно ("тайны мадридского двора") - везде в документации: "... процесс ..." - но они пишут документацию так небрежно, что могут и не различить эти понятия.

4 класса приоритетов по 32 уровня. NORMAL класс может иметь как динамические приоритеты, так и абсолютные (устанавливается в config.sys) все остальные - абсолютные
На уровне ниток.
Приоритеты наследуются нитками.