[Владимир Е. Зюбин 0]

Все зависит от задачи. Могу поспорить, что 15 программистов потратят больше времени на совещания и в результате код будет более объемным. Простой пример: при разработке и вндрении протокола требуется изменить/добавить новые возможности; один прогаммист делает все молча за 15 минут вместе с отладкой, двое перекидываются коротким описанием и структурами за пол часа, 10 -- два часа спорят, какой протокол применить (не выдумывать же новый!?)

Ну есть еще и поддержка.

Если вам придется по этому протоколу другие устройства подключать?

Искать того самого молчаливого программиста?

В принципе, неплохая гарантия занятости.

Основная мысль тут (как я понял): рост затрат на организацию согласованной работы коллектива.

Проблема в том, что затраты растут нелинейно, экспоненциально.

По аналогии с параллельным программированием (многопроцессорным):

Два программиста решают одну и туже задачу не в два раза быстрее, а в полтора, три - в 1,7 раз, и т.д., а потом с ростом числа программистов наступает насыщение... а потом - увеличение времени на разработку. Т.е. наиболее эффективные проекты (с точки зрения КПД) - это минимальные по числу участников (если программисты - одинаковые с точки зрения квалификации).

 

А в простых задачах будет наблюдаться рост времени сразу же, при появлении уже второго программиста.

 

Что же касается ОС, то, разумеется, ОС может существенно сократить сроки, и предоставляет всякие полезные штуки в виде кучи драйверов, стеков протоколов, среды разработки, полезных утилит и т.д. и т.п.

 

Другое дело, что ОС типа QNX от версии к версии мигрирует в сторону ОС типа Виндоз. Но и при этом ОС типа Виндоз становится все более и более надежными.

 

Небольшая революция (ну или большая) грядет (и уже началась) в связи с переходом на многоядерные архитектуры... коренным образом меняются подходы... Архитектурно, ОС типа QNX имеют некое преимущество за счет модульности, по сути же - это преимущество легко теряется. Тем более, что имеющиеся шедулеры-планировщики не особо и подходят для таких архитектур (алгоритмически), и их все равно надо переписывать.

[TMX 0]

мы тоже обычно пишем на С:

и логику работы проще отлаживать на РС, чем на целевом процессоре (можно организовать вывод в файл, на графики и т.п.) и все остальные преимущества ЯВУ.

а дальше случаи из практики:

1. Кривой компилятор (holtek) - генерит код просто огромных размеров, при этом не умеет использовать особенности процессора. пришлось писать на асме работу с флагами, прерываниями и т.п. (не входило приложение в 8 Кб)

2. В некоторых компиляторах не предусмотрена обработка вложенных прерываний (контекст сохраняется в оверлее).

3. Обработка быстрых прерываний в PIC.

4. Монитор событий с переключением банков РОН в F2MC

 

в общем, это разговор об одном и том же, к тому же не по теме ветки.

[TMX 0]

По теме.

Любопытно, что отмечается несколько подходов:

1. Использование автоматной логики.

2. Использование обработки событий.

 

которые в свою очередь делятся на:

1.1. Реализация автоматов, непосредственно в суперцикле.

1.2. Использование ОС и языка технологического программирования для описания тех же автоматов в суперцикле.

 

2.1. привязывание обработчиков к монитору или к прерываниям

2.2. привязывание обработчиков срествами ОС к тем же прерываниям.

 

при этом, споры идут между 1.1 и 1.2 и между 2.1 и 2.2, а это не так интересно, как противопоставление 1 и 2. Т.е. есть ОС, нет ОС - это ерунда. Важно как выбрать модель представления на этапе проектирования, чтобы она сама себя не погребла при развитии системы.

 

В частности, меня интересует, как, например, olej планировал свою систему управления при обработке событий.

[Olej 0]

В частности, меня интересует, как, например, olej планировал свою систему управления при обработке событий.

 

С удовольствием, ... но я не совсем понял что именно вы имеете в виду?

Много о том (если я правильно предполагаю) обсуждалось (-ется) здесь:

http://qnxclub.net/modules.php?name=Forums...viewtopic&t=268

http://qnxclub.net/modules.php?name=Forums...viewtopic&t=279

http://qnxclub.net/modules.php?name=Forums...viewtopic&t=276

http://qnxclub.net/modules.php?name=Forums...viewtopic&t=277

Кроме того, предполагаю, это будет уже совсем другое обсуждение, слабо относящееся к этой теме ;).

[Владимир Е. Зюбин 0]

По теме.

Любопытно, что отмечается несколько подходов:

1. Использование автоматной логики.

2. Использование обработки событий.

 

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

 

В частности, меня интересует, как, например, olej планировал свою систему управления при обработке событий.

 

По этому поводу вспоминается далекий 1994-й, когда мне долго расказывали про преимущества QNX,

а на мой вопрос "ну и сколько же у Вас процессов" ответили - два, а на вопрос "а почему не три или четыре", ответили "а больше мы боимся, т.к. можем не успеть"...

 

Ну, а вообще я присоединяюсь к вопросу, т.к. у меня до сих пор где-то внутри живет стойкое убеждение, что средствами ОС решаются немного не те задачи, что решаются в промавтоматизации.

Стратегия реализации управляющих алгоритмов на голой ОС - совершенно непонятна.

[Olej 0]

Небольшая революция (ну или большая) грядет (и уже началась) в связи с переходом на многоядерные архитектуры... коренным образом меняются подходы... Архитектурно, ОС типа QNX имеют некое преимущество за счет модульности, по сути же - это преимущество легко теряется. Тем более, что имеющиеся шедулеры-планировщики не особо и подходят для таких архитектур (алгоритмически), и их все равно надо переписывать.

 

"Слухи сильно преувеличены"(с) ...

"Архитектурно, ОС типа QNX имеют некое преимущество за счет модульности..." - это неверное утверждение, которое должно звучать так: "Архитектурно, ОС типа QNX имеют некое преимущество за счет микроядерности и обмена сообщениями..." - что далеко не то, что было раньше. Именно поэтому: а). микроядерные архитектуры (не только QNX) очень легко вписываются в SMP б). SMP именно в QNX давно и успешно реализовано, и очень эффективно, по оценкам выше, чем в любом другом коммерческом продукте.

 

По этому поводу вспоминается далекий 1994-й, когда мне долго расказывали про преимущества QNX,

а на мой вопрос "ну и сколько же у Вас процессов" ответили - два, а на вопрос "а почему не три или четыре", ответили "а больше мы боимся, т.к. можем не успеть"...

 

Ну так это же вообще ни о чём не говорит - это просто у вас компания такая собралась ... слабая - вот они и боятся.

Даже интересно мне стало за них? : а с чего же это они решили, что успеть/не успеть хоть как-то коррелирует с числом процессов, потоков? из досужих домыслов?

"Не стреляйте в пианиста - он играет как умеет"(с).

[Goroshko 0]

По теме.

Любопытно, что отмечается несколько подходов:

1. Использование автоматной логики.

2. Использование обработки событий.

 

Любопытно еще и то, что некоторые из использующих "автоматный"/FSM подход считают, что они проектируют событийные архитектуры.

И наоборот, кстати. :-)

 

Для разрешения этого конфликта неплохо было бы определится с понятиями, что такое автоматная логика, а что такое обработка событий.

Простейший пример: Оконная процедура win32 - классический автомат без памяти, в цикле обрабатывающий события окна.

Да любая GUI это автоматная логика обработки событий. Так что объясните пожалуйста что же все таки имелось в виду под этой класификацией.

 

Может быть речь идет о разнице между циклической обработкой и условно событийной обработкой?

В стиле

for (;;)

{

if(Condition) DoSomthing();

if(AnotherCondition) DoSomthingElse();

}

или

for (;;)

{

SleepUntil(Condition);

DoSomthing();

}

for (;;)

{

SleepUntil(AnotherCondition);

DoSomthingElse();

}

в паралельных потоках.

 

Я говорю условной, потому что в конечном счете где то for есть в обеих моделях :-)

Только в первой распределение ресурсов вычислительной системы ложится на плечи разработчика, и он должен распределять вычислительный ресурс между своими задачами, а также следить за тем, чтобы выполнение менее важных задач не прпятсвовало выполнению более важных, а во втором случае средсвами ОС (или своими силами если хотите) эта задача отдается подсистеме планирования ОС.

Изменено 30 мая, 2006 пользователем Goroshko Egor

[Olej 0]

Стратегия реализации управляющих алгоритмов на голой ОС - совершенно непонятна.

 

А чего ж там совершенно непонятного? ;)

Я мог бы назвать вам фирму (не стану я это делать только потому, что не хочу делать никому ни рекламу, ни антирекламу - кто как поймёт), которая уже лет 10 (более) очень успешно внедряет системы диспетчерской централизации на ж/д, но "лабает" это в голой ОС QNX, и делают это очень успешно, и это очень дорогие системы и отрасль, а соответственно - и сложные (существенно сложнее традиционной конвейерной автоматизации).

Это не значит, что так нужно делать, но, как видите, так можно делать.

И всё там будет делаться точно так, как в МЭК реализациях: цикличность опроса, периодичность обработки и т.д. Ведь МЭК со своим runtime - это ничего более чем надстройка, чем голая ОС вам не такая же надстройка, что так "совершенно непонятна": надстройте над этой надстройкой ещё одну - CoDeSys ... похоже?

[Владимир Е. Зюбин 0]

По теме.

Любопытно, что отмечается несколько подходов:

1. Использование автоматной логики.

2. Использование обработки событий.

 

Любопытно еще и то, что некоторые из использующих "автоматный"/FSM подход считают, что они проектируют событийные архитектуры.

И наоборот, кстати. :-)

 

Для разрешения этого конфликта неплохо было бы определится с понятиями, что такое автоматная логика, а что такое обработка событий.

 

логично... на мой взгляд - "автоматная логика" (событийный полиморфизм) - это идеальный подход для обработки событий, когда их много.

 

Может быть речь идет о разнице между циклической обработкой и условно событийной обработкой?

В стиле

for (;;)

{

if(Condition) DoSomthing();

if(AnotherCondition) DoSomthingElse();

}

или

for (;;)

{

SleepUntil(Condition);

DoSomthing();

}

for (;;)

{

SleepUntil(AnotherCondition);

DoSomthingElse();

}

в паралельных потоках.

 

непонятно, в чем тут разница. Т.к. SleepUntilCondition в конечном случае вырождается в if(Condition), разве что где-то в недрах планировщика ОС...

 

Тут можно говорить об отличиях между многозадачным логическим параллелизмом (ОС) и многопоточным логическим параллелизмом ("лом", round-robin, Stand-alone, кооперативная многопоточность на уровне задачи)... но ни к автоматам, ни к обработке событий это особого отношения не имеет.

 

Я говорю условной, потому что в конечном счете где то for есть в обеих моделях :-)

Только в первой распределение ресурсов вычислительной системы ложится на плечи разработчика, и он должен распределять вычислительный ресурс между своими задачами, а также следить за тем, чтобы выполнение менее важных задач не прпятсвовало выполнению более важных, а во втором случае средсвами ОС (или своими силами если хотите) эта задача отдается подсистеме планирования ОС.

 

В средах массового параллелизма выгоднее не заниматься планированием, а выполнять задачу, в средах единичного параллелизма, возможно применение многозадачного параллелизма на уровне ОС...

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

 

 

Стратегия реализации управляющих алгоритмов на голой ОС - совершенно непонятна.

А чего ж там совершенно непонятного? ;)

Я мог бы назвать вам фирму (не стану я это делать только потому, что не хочу делать никому ни рекламу, ни антирекламу - кто как поймёт), которая уже лет 10 (более) очень успешно внедряет системы диспетчерской централизации на ж/д, но "лабает" это в голой ОС QNX, и делают это очень успешно, и это очень дорогие системы и отрасль, а соответственно - и сложные (существенно сложнее традиционной конвейерной автоматизации).

Это не значит, что так нужно делать, но, как видите, так можно делать.

И всё там будет делаться точно так, как в МЭК реализациях: цикличность опроса, периодичность обработки и т.д. Ведь МЭК со своим runtime - это ничего более чем надстройка, чем голая ОС вам не такая же надстройка, что так "совершенно непонятна": надстройте над этой надстройкой ещё одну - CoDeSys ... похоже?

 

Насколько я понял, "стратегия" эта в стиле "программирую на Си как придется", (и, прошу прощения, CoDeSys представляет совершенно другой функционал и концептуальные средства программирования, чем обычный Си)...

 

Вот и непонятно. Это ли имеется ввиду? А если это, то зачем они вообще ОС используют?

для TCP/IP? Почему в таком случае именно QNX? Надежность? Слова.. слова... слова...

 

"Слухи сильно преувеличены"(с) ...

"Архитектурно, ОС типа QNX имеют некое преимущество за счет модульности..." - это неверное утверждение, которое должно звучать так: "Архитектурно, ОС типа QNX имеют некое преимущество за счет микроядерности и обмена сообщениями..." - что далеко не то, что было раньше. Именно поэтому: а). микроядерные архитектуры (не только QNX) очень легко вписываются в SMP б). SMP именно в QNX давно и успешно реализовано, и очень эффективно, по оценкам выше, чем в любом другом коммерческом продукте.

Хорошо, пусть вместо "модульности" будет "микроядерность"... нет возражений.

 

По этому поводу вспоминается далекий 1994-й, когда мне долго расказывали про преимущества QNX,

а на мой вопрос "ну и сколько же у Вас процессов" ответили - два, а на вопрос "а почему не три или четыре", ответили "а больше мы боимся, т.к. можем не успеть"...

Ну так это же вообще ни о чём не говорит - это просто у вас компания такая собралась ... слабая - вот они и боятся.

Даже интересно мне стало за них? : а с чего же это они решили, что успеть/не успеть хоть как-то коррелирует с числом процессов, потоков? из досужих домыслов?

"Не стреляйте в пианиста - он играет как умеет"(с).

 

Он играет как умеет, да и пианино расстроено... Увы, но априорный анализ динамического поведения системы в средах с многозадачной организацией логического параллелизма весьма затруднен. Вот люди и прикидывают шансы...

[Olej 0]

Стратегия реализации управляющих алгоритмов на голой ОС - совершенно непонятна.

Насколько я понял, "стратегия" эта в стиле "программирую на Си как придется", (и, прошу прощения, CoDeSys представляет совершенно другой функционал и концептуальные средства программирования, чем обычный Си)...

 

Ну так вы тогда так и говорите: "стратегия реализации управляющих алгоритмов программирую на Си как придется - совершенно непонятна." И это уже совсем другой разговор, о том, какие средства проектирования подходят, а какие не подходят. Кому то, как я назвал - и С очень даже подходит, кто-то над С сделает технологическую надстройку, как например в системе ДЦ ЮГ, которая более 20 лет успешно шаг за шагом внедряется, кто-то сделает другую надстройку - CoDeSys или ISaGRAF и МЭК, кто-то - Рефлекс ;). Средства изображения целевой алгоритмики ну никакого касательства не имеют к вопросам параллелизмов, диспетчирования, управления ресурсами и всем другим вещам, которые относятся к функциональности ОС или отсутствия таковой.

 

Вот и непонятно. Это ли имеется ввиду? А если это, то зачем они вообще ОС используют?

для TCP/IP? Почему в таком случае именно QNX? Надежность? Слова.. слова... слова...

 

Пусть и для наличия стека TCP/IP. Вы когда-нибудь реально писали что-либо в программировании сетевых обменов? Это на словах "слова.. слова... слова..." - а реально нет такого "стека TCP/IP", а есть только стек TCP/IP в конкретной его реализации: BSD, Windows, ... и каждый включает в себя только какое-то подмножество возможностей из описанных в 3000 RFCs.

И при чём здесь упоминание QNX к месту или не к месту? если мы говорим вообще о принципиальном использовании или не- ОС вообще, всякой.

Надёжность? да, пусть надёжность - этого тоже может быть достаточно: я под QNX совершенно спокойно предположу работу (программ) на одном процессоре: PLC, сервера тэгов, SCADA системы с её HMI компонентой + ... в качестве просто параллельных задач, не сомневаясь, что они не завалят друг-друга и за несколько лет невыключаемого режима... чего даже под Linux/FreeBSD/etc. не представлю, под ... "другими ОС" ;) - так это "во сне приснится - не проснёшься"(с).

Вот 1 из "по-быстрому" (не самых свежих) попавшихся переводов, который хоть отчасти объясняет почему так происходит:

http://www.cniil.org/QNX_NEUTRINO_RTOS_V6_2_0.html

Вот такая проза, хотя она, конечно, к высокой девственности теории касательства и не имеет... как и к предмету этого разговора ;), поскольку не о QNX мы говорим, а обо всём сразу - говорить не стоит.

 

По этому поводу вспоминается далекий 1994-й, когда мне долго расказывали про преимущества QNX,

а на мой вопрос "ну и сколько же у Вас процессов" ответили - два, а на вопрос "а почему не три или четыре", ответили "а больше мы боимся, т.к. можем не успеть"...

Ну так это же вообще ни о чём не говорит - это просто у вас компания такая собралась ... слабая - вот они и боятся.

Даже интересно мне стало за них? : а с чего же это они решили, что успеть/не успеть хоть как-то коррелирует с числом процессов, потоков? из досужих домыслов?

"Не стреляйте в пианиста - он играет как умеет"(с).

Он играет как умеет, да и пианино расстроено... Увы, но априорный анализ динамического поведения системы в средах с многозадачной организацией логического параллелизма весьма затруднен. Вот люди и прикидывают шансы...

 

Во-первых, для того, чтобы "прикидывать шансы" нужно хорошо понимать предмет того, что ты прикидываешь... с QNX, как частность, особая история, с ним достаточно многие "работали", но из всех работающих, может, только 10:1 дали труд себе разобраться что там происходит, и чем это отличается от ... "других ОС" ;) ... некоторых, а для того, чтобы это понимать есть только единственнный путь, к сожалению: писать, писать и писать "ручками", и анализировать что из этого получается, и удивляться, что получается не совсем так, как предполагается...

 

Во-вторых, и с "априорным анализом динамического поведения системы в средах с многозадачной организацией логического параллелизма" не всё так запущено, давно и много сделано "в эту сторону", вот хотя бы только малые намёки:

http://qnxclub.net/files/articles/rta/rta.doc

http://qnxclub.net/files/articles/rms/rms.doc

- но и это не так обязательно, если хорошо представлять, что и как там происходит "на деле", а не на уровне хвалебных описаний производителей каждой из ОС как раз на уровне "слова.. слова... слова...".

[Владимир Е. Зюбин 0]

Стратегия реализации управляющих алгоритмов на голой ОС - совершенно непонятна.

...

Насколько я понял, "стратегия" эта в стиле "программирую на Си как придется", (и, прошу прощения, CoDeSys представляет совершенно другой функционал и концептуальные средства программирования, чем обычный Си)...

Ну так вы тогда так и говорите: "стратегия реализации управляющих алгоритмов программирую на Си как придется - совершенно непонятна."

Жалко, что Вы опять на success-story разговор переводите. А вопрос о стратегии. И о месте ОС в этой стратегии. Я вот на Рефлексе программирую, так вообще об ОС не думаю... мне легко и приятно, голова свободна для решения конкретных целевых задач, что под Виндовозом, что под любой другой ОС, или без оной...

 

Вот и непонятно. Это ли имеется ввиду? А если это, то зачем они вообще ОС используют?

для TCP/IP? Почему в таком случае именно QNX? Надежность? Слова.. слова... слова...

 

Пусть и для наличия стека TCP/IP. Вы когда-нибудь реально писали что-либо в программировании сетевых обменов?

 

Да не нужно все это. Это системный уровень. Когда я пишу на Рефлексе, мне что TCP/IP, что UDP/IP,

что USB, что RS-485... голова занята алгоритмом, а не протоколами обмена. А сетевые протоколы я реализовывал, и что такое сокет знаю.

 

Надёжность? да, пусть надёжность - этого тоже может быть достаточно: я под QNX совершенно спокойно предположу работу (программ) на одном процессоре: PLC, сервера тэгов, SCADA системы с её HMI компонентой + ... в качестве просто параллельных задач, не сомневаясь, что они не завалят друг-друга и за несколько лет невыключаемого режима... чего даже под Linux/FreeBSD/etc. не представлю, под ... "другими ОС" ;) - так это "во сне приснится - не проснёшься"(с).

 

Значит, Надежность. Спасибо. Понятно. Не понятно, правда, почему у QNX надежность выше, чем у Виндовза или Линукса, ну да ладно. Лично на мой взгляд, QNX становится все более громоздкой ОС и движется в сторону Виндовз, а Виндовз становится все более надежной ОС.

 

...Даже интересно мне стало за них? : а с чего же это они решили, что успеть/не успеть хоть как-то коррелирует с числом процессов, потоков? из досужих домыслов?

"Не стреляйте в пианиста - он играет как умеет"(с).

Он играет как умеет, да и пианино расстроено... Увы, но априорный анализ динамического поведения системы в средах с многозадачной организацией логического параллелизма весьма затруднен. Вот люди и прикидывают шансы...

Во-первых, для того, чтобы "прикидывать шансы" нужно хорошо понимать предмет того, что ты прикидываешь... с QNX, как частность, особая история, с ним достаточно многие "работали", но из всех работающих, может, только 10:1 дали труд себе разобраться что там происходит, и чем это отличается от ... "других ОС" ;) ... некоторых, а для того, чтобы это понимать есть только единственнный путь, к сожалению: писать, писать и писать "ручками", и анализировать что из этого получается, и удивляться, что получается не совсем так, как предполагается...

У меня лично нет времени на реинжиниринг ОС. Ну а вообще, вполне логично ожидать, что эту информацию должен предоставить производитель.

 

Во-вторых, и с "априорным анализом динамического поведения системы в средах с многозадачной организацией логического параллелизма" не всё так запущено, давно и много сделано "в эту сторону", вот хотя бы только малые намёки:

http://qnxclub.net/files/articles/rta/rta.doc

http://qnxclub.net/files/articles/rms/rms.doc

- но и это не так обязательно, если хорошо представлять, что и как там происходит "на деле", а не на уровне хвалебных описаний производителей каждой из ОС как раз на уровне "слова.. слова... слова...".

Не сомневаюсь, что люди над этим вопросом работают, пишут докторские и т.д. Кстати, судя по статьям,

вопросы рассматриваются малоинтересные, типа успеет-не успеет, т.е. вопросы функционирования в условиях ограниченных ресурсов. Честно признаться, на практике вообще об этом не задумывался... вернее, задумался один раз, посмотрел на вычислительные ресурсы - запасов >92%, т.е. порядок с лишним... на 300 МГц "Пне"... не будет хватать поставлю 3 гигагерца, не будет хватать, разобью задачу на 10 процессоров... и особых теорем для этого не нужно...

 

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

 

Ну и вообще, человеку надо создать алгоритм, а ему говорят: Нет! сначала стек протоколов изучи, покопайся в ОС, создай проблемно-ориентированную библиотеку классов и докажи десять теорем по алгоритмам планирования. ;-) Плохой какой-то подход.

Это несерьезно.

Изменено 31 мая, 2006 пользователем Владимир Е. Зюбин

[stass 0]

Не понятно, правда, почему у QNX надежность выше, чем у Виндовза или Линукса, ну да ладно.

 

Ну как же - вполне очевидно. Если в Windows у вас откажет, например, IDE контроллер и унесёт за собой соответствующий драйвер, то вся ОС уйдёт, в лучшем случае, в затяжной ребут. В худшем - вообще повиснет.

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

[Владимир Е. Зюбин 0]

Не понятно, правда, почему у QNX надежность выше, чем у Виндовза или Линукса, ну да ладно.

 

Ну как же - вполне очевидно. Если в Windows у вас откажет, например, IDE контроллер и унесёт за собой соответствующий драйвер, то вся ОС уйдёт, в лучшем случае, в затяжной ребут. В худшем - вообще повиснет.

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

 

Мне неочевидно, почему "IDE контроллер унесет с собой драйвер" и куда он его унесет, и какой смысл "поднимать" драйвер при отказавшем железе, и кто будет его "поднимать"...

 

Я согласен, что теоретически устойчивость ПО при модульном (микроядерном) построении системы выше. Но как это измерить в числах, я не понимаю. Ну, хорошо, есть статистика. Но по статистике, последние версии ОС Виндоуз весьма устойчиво работают, на уровне архитектуры там тоже очень грамотные решения. Есть и специализированные модели ОС, типа CE.

[Goroshko 0]

Не сомневаюсь, что люди над этим вопросом работают, пишут докторские и т.д. Кстати, судя по статьям,

вопросы рассматриваются малоинтересные, типа успеет-не успеет, т.е. вопросы функционирования в условиях ограниченных ресурсов. Честно признаться, на практике вообще об этом не задумывался... вернее, задумался один раз, посмотрел на вычислительные ресурсы - запасов >92%, т.е. порядок с лишним... на 300 МГц "Пне"... не будет хватать поставлю 3 гигагерца, не будет хватать, разобью задачу на 10 процессоров... и особых теорем для этого не нужно...

 

Да похоже у вас довольно простые и не замысловатые задачи :-)

Мы вот в своем проекте вторую неделю байтики считаем и по третьему проходу вычищаем все лишнее. И каждую лишнюю милисекунду выжимаем из алгоритмов. А целевая платформа - 4 процессорный Intel с 4 Гб памяти. А все равно считаем, оптимизируем, переписываем так что бы в кеш вовремя попадало все что надо... Что бы памяти лишней не жрало. Насчет производительности аппаратуры - это миф. По тому что когда вы говорите заказчику - да тут надо проц посильнее поставить, памяти побольше, а он считает, считает... И говорит, знаете, дорогие мои, вы конечно умные ребята, но вон у них работате на более дешевой аппаратуре и куплю я систему наверно все таки у них.

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

 

Поэтому там где конкуренция есть и теоремы изучают (или не изучают и прогорают).

Изменено 31 мая, 2006 пользователем Goroshko Egor

[Olej 0]

Ну как же - вполне очевидно. Если в Windows у вас откажет, например, IDE контроллер и унесёт за собой соответствующий драйвер, то вся ОС уйдёт, в лучшем случае, в затяжной ребут. В худшем - вообще повиснет.

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

 

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

 

Но как это измерить в числах, я не понимаю. Ну, хорошо, есть статистика. Но по статистике, последние версии ОС Виндоуз весьма устойчиво работают, на уровне архитектуры там тоже очень грамотные решения. Есть и специализированные модели ОС, типа CE.

 

Меня мало вдохновляет "фирменная" статистика: "посмотрите насколько мы круты"...

Я просто знаю (могу перечислить: в какой стране, где и как, в каком проекте):

- QNX системы в необслуживаемом режиме работают не выключаясь а). 14 лет б). 20 лет ... - выходят из строя потому, что вентиляторы за это время насосали в корпус пыли столько, что там стал сплошной "валенок", и все кулера стали;

- Linux в качестве роутера достаточно надёжно себя показывает 3-5-7 лет...

- Windows (из вот "весьма устойчиво работающих" суффиксов) - период полураспада 3-4 мес. - вот только вчера в моей фирме выяснилось, что в уже поставленных crytical mission отрасли SCADA станции умирают, в среднем, за 21 день ... это не мои проекты, но я их предупреждал ... но "нет пророка в своём отечестве"(с) - теперь они по объектам будут ездить на 20-й день ... "накануне"? ;)