О фатальных программных ошибках и т.п.

Pazke, 29.01.2004 11:51:47:

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

 

Это каким образом эти потребности анализа не нужны для однопоточной задачи? Что, если ввод вывод вызывает прерывание задачи, то это не отразиться на временной диаграмме работы однопоточной задачи? Или как планировщик ОС работает с однопоточной программой никак на нее не влияет? Или мы говорим об одной задаче на процессоре и точка - никаких ОС?

DOS - это тоже OS.

Balancer, 29.01.2004 22:27:25:

Для КА реально малое время отклика нужна для мало каких процессов. На это время всё остальное и задвинуть можно. А так - да, отложенная обработка прерываний.

 

Многие железяки не могут принять повторных прерываний, пока предыдущее не обработано/сброшено. Или просто теряют предыдущие данные. Тот RS232C запросто потеряет данные.

Но у нас тут изъян в самом начале есть. Мы строим однопроцессорную систему, а это ущербный подход.

 

А откуда такая уверенность? Многопоточность на многопроцессорной системе - еще лучше. Дальше уже кластеризация идет - там вообще не обязательно иметь однородные системы. Да и просто процессоров параллельных бывает много разных классов. Когда была такая классификация (когда я учился в универе и нам читали параллелизм и супер компьютеры) - SISD, SIMD, MISD, MIMD. S - Single, M - Multiple, I - Instruction, D - Data.

SISD - single intructon single data - x86 типичный пример.
SIMD - векторные Креи. И расширение в Пнях известные.
MISD - системы параллельного анализа одних и тех же данных - типичный пример когда CPU и видеокарточка разделяют память, но используют по разному - один для рисовки, а другой может и еще что-нибудь.
MIMD - например SMP архитектура. Кластеры разные.

Особенно для таких систем. Даже ПК давно движется к распределению задач (многие ли из нас на MFM-винтах и VGA-видеокартах сидят?). Для нормального КА каждый исполнительный орган должен быть снабжён своим микроконтроллером, отвечающим за работу с ним и отчитывающимся и управляемым центральным (возможно - несколькими) процессором. Эдакая аппаратная многопроцессность (не многопоточность)

 

Одно другому не помеха. В случае хоть как-то связанных процессов (сильно и слабо - по последним есть велкилепная книжка Тони Хоара, переведенная Аней Бульонковой) надо синхронизовать как-то их. Если они не связаны, то пусть и живут отдельно.

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

 

Чем проще? Если есть взаимодействие, то проблемы те же.

Centuriones, 30.01.2004 22:58:43:

DOS - это тоже OS.

 

А там обработка прерываний тоже есть и независимо от программ. Просто есть возможность нагло вручную закрыть прерывания - что потом получается - надо объяснять? Кроме того, не встечали вы там видного воителя Генерала Файлуру? Типа вопрос от ОС - Abort, Retry, Ignore? - а ваша прога висит и не знает, что ОС уже вовсе не читает файл, а просит интерактивного совета. То-то автоматы сработали. Вообщем, связи уже с программой никакой, аппарат давно вошел в плотные слои чего-то там и сгорел.

Mishka, 31.01.2004 00:24:41 :

А там обработка прерываний тоже есть и независимо от программ.

 

 

Но я могу вектора прерываний и переназначить. Обработчики поменять. Возможностей много.

Mishka, 31.01.2004 00:19:50:

Многие железяки не могут принять повторных прерываний, пока предыдущее не обработано/сброшено. Или просто теряют предыдущие данные. Тот RS232C запросто потеряет данные.

 

Ну и зачем нам RS-232 на КА? По-моему, это тот случай, когда не задачу под железки подгонять надо, а железки под задачу

>>Но у нас тут изъян в самом начале есть. Мы строим однопроцессорную систему, а это ущербный подход.
>А откуда такая уверенность? Многопоточность на многопроцессорной системе - еще лучше.

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

SISD - single intructon single data - x86 типичный пример.
SIMD - векторные Креи. И расширение в Пнях известные.
MISD - системы параллельного анализа одних и тех же данных - типичный пример когда CPU и видеокарточка разделяют память, но используют по разному - один для рисовки, а другой может и еще что-нибудь.
MIMD - например SMP архитектура. Кластеры разные.

Вот вторые две концепции в описанном тобой виде кажутся мне чем-то неестественным и надуманным

>В случае хоть как-то связанных процессов (сильно и слабо - по последним есть велкилепная книжка Тони Хоара, переведенная Аней Бульонковой) надо синхронизовать как-то их. Если они не связаны, то пусть и живут отдельно.

А куда, вдруг, списали асинхронное взаимодествие?

>Чем проще? Если есть взаимодействие, то проблемы те же.

Не те же. Если у тебя законченные самостоятельные, но взаимодействующие модули, то число состояний на их интерфейсах на порядки порядков меньше, чем для однопроцессорной системы, обрабатывающей всё и для таких систем гораздо лучше формализуются граничные условия, ограничения и т.п. Что приводит к сильному упрощению тестирования.

Mishka, 31.01.2004 00:24:41:

Кроме того, не встечали вы там видного воителя Генерала Файлуру? Типа вопрос от ОС - Abort, Retry, Ignore? - а ваша прога висит и не знает, что ОС уже вовсе не читает файл, а просит интерактивного совета.

 

А что, что-то подобное на КА, случается, ставят? Впрочем, согласен, американцы на подобное способны. Они как-то умудрились NT воткнуть в систему управления ходом фрегата и получить несколько часов бездействия на ровном месте из-за падения системы.

Нормальные же люди, всё же, системы бытового уровня в критичные к таким вещам системы не ставят

Думаю, не КА вокруг ОС конструировать нужно и не подгонять имеющиеся ОС и КА. А ОС под КА писать Благо, ресурсы там пока совсем смешные обрабатываются и программистские затраты, скорее всего, человекомесяцами измеряются, а не человекотысячелетиями

Balancer, 31.01.2004 01:06:46 :

Ну и зачем нам RS-232 на КА? По-моему, это тот случай, когда не задачу под железки подгонять надо, а железки под задачу

 

Это просто пример. В принципе, подобного рода ограничения есть для многих модулей.

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

 

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

Вот вторые две концепции в описанном тобой виде кажутся мне чем-то неестественным и надуманным

 

MIMD - любой многопроцессорный вариант сервера - оно и есть - на каждый процессор своя последовательно команд и свои данные.

MISD - это когда данные одни, а алгоритмы к ним разные прилагаются. Это больше специализированные компы. Я видел где-то описание спец-процессоров по взлому паролей несколькими параллельными алгоритмами.

А куда, вдруг, списали асинхронное взаимодествие?

 

Ром, а в чем оно проявляется? Общие переменные - синхронизация обязательна. Рандеву - тоже самое. Остается только посылка сообщений, но и там есть проблемы. Например, с подтверждением, надежностью - посмотри на протокол TCP/IP - там многое вылезло. Если оставить чистые ассинхронные сообщения, то как узнать, что коллега получил сообщение?

Не те же. Если у тебя законченные самостоятельные, но взаимодействующие модули, то число состояний на их интерфейсах на порядки порядков меньше, чем для однопроцессорной системы, обрабатывающей всё и для таких систем гораздо лучше формализуются граничные условия, ограничения и т.п. Что приводит к сильному упрощению тестирования.

 

Принцип разделяй и властвуй действует везде. Вот только почему ты взял, что взаимодествие таких модулей не надо будет просчитывать при параллельной работе? На это уже указывали выше. Ариан гробанулась как раз из-за того, что кто-то не учел взаимодействие модулей - Ник хорошо сказал.

Balancer, 31.01.2004 01:10:19:

А что, что-то подобное на КА, случается, ставят?

 

Это я в ответ Centuriones писал. Хотя я не уверен, ставят ли амеры такое на КА. А фрегат под управлением НТ - это был эксперимент - MS долго всех убеждал, что их системы не хуже, чем у других - вот и провели эксперимент - теперь флот не хочет НТ. Я знаю еще пару историй - например, Ratheon наш заказчик, только говорить ничего не имею права.

2 Роман: делать многозадачность аппаратно с помощью контроллеров, или используя РТ операционку - суть дела не меняет. В системеобьективно существует проблема синхронизации и управления ресурсами, так как наши модули (потоки или микроконтроллеры) должны делить эти ресурсы между собой, будь это общая шина данных (из-за чего всё и началось) или что-то ещё. Всё же, исправить программу налету сильно легче, чем переделывать аппаратную часть. И зачем ты упомянул асинхронное взаимодействие? Любая асинхронная точка соприкосновения требует синхронизации (семафор, мутекс) - на то она и асинхронная. И потом, не забывай, что именно из-за асинхронного взаимодействия (пайпы) у Pathfinder'а и начались проблемы.

Насчёт простых, законченных контроллеров - так и в той системе были простые, законченные автоматы: поток обслуживания шины - простой, всё, что делает - это раздает ресурсы шины желающим; поток сбора научной информации - тоже простой - опрашивает градусники и барометры. Что же тебе ещё нужно?

Насчёт НТ - зато сейчас WindowsСЕ управляет BMW класса 7. Кстати, никто не знает, что же за история произошла на том корабле? В смысле, подробности.

Ещё история, правда не из области космоса и военки, но тоже забавно (прочитал или в TIME или в Newsweek), причём технической детали происшествия я не знаю, а из-за иронии произошедшего. В одном из округов проводили голосования, и из-за ошибки в программе СУБД было потеряно около 250 тыс. голосов - просто так - вжик, и нету. Но самое убийственное в истории то, что они не стали проводить повторное голосование, потому что, слушайте сюда - эти 250 тыс. голосов уже не повлияли бы на исход выборов, был очевиден сильный разрыв между кандидатами. Вот так-то - а говорят - каждый голос важен. Короче, вот этим горе-программистам и ноги поотрывать не мешало бы. Вообще, удивляет раздолбайсво в проведении выборов - взламывай что хочешь, никаких дупликаций на бумаге тебе, ничего.

Rada, 31.01.2004 04:29:45:

2 Роман: делать многозадачность аппаратно с помощью контроллеров, или используя РТ операционку - суть дела не меняет.

 

Меняет. При сбое центарльного процессора в одной задаче (завис) откажет вся система, при сбое контроллера - откажет только один компонент системы. Если он не важен для жизни аппарата или дублирован - можно будет продолжить работу дальше Я уже молчу про поышение надёжности. Хотя "контактов" и больше (что по идее снижает андёжность системы в целом), но система становится работоспособной при локальных повреждениях.

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

Ну так и взаимодействие протоколов интерфейсов модулей у нас же тоже программное.

>И зачем ты упомянул асинхронное взаимодействие? Любая асинхронная точка соприкосновения требует синхронизации (семафор, мутекс) - на то она и асинхронная.

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

>И потом, не забывай, что именно из-за асинхронного взаимодействия (пайпы) у Pathfinder'а и начались проблемы.

Но, как я понял, это были пайпы на одном процессоре

Что же до обращения к общим переменным, которые упоминал Mishka - не должно их быть. Должно быть только интерфейсное взаимодействие.

>Насчёт простых, законченных контроллеров - так и в той системе были простые, законченные автоматы: поток обслуживания шины - простой, всё, что делает - это раздает ресурсы шины желающим; поток сбора научной информации - тоже простой - опрашивает градусники и барометры. Что же тебе ещё нужно?

Ну так и как он тогда мог зависнуть из-за переполнения какой-то мелочи типа модуля флешпамяти?

Balancer>Меняет. При сбое центарльного процессора в одной задаче (завис) откажет вся система, при сбое контроллера - откажет только один компонент системы.

Жаловался мне один знакомый - владелец маленького автосервиса. Сейчас производители автомобилей стремятся делать машины так, что бы по максимуму затруднить их обслуживание и ремонт в неспециализированных сервисах, повышая уровень компьютеризации автомобилей. При этом микроконтроллеры понатыканы повсюду - даже подъемом/опусканием стекол управляет отдельный компьютер в каждой двери, получая команды от центрального компьютера. Так вот один клиент этого автосервиса купил в Германии фольксваген (забыл какой), и на границе у него все стекла как опустились, так больше никак не поднимались. Пришлось мужику до самой Риги ехать "с ветерком". А дело было зимой, мороз -20С. А всех проблем - сброс флажков в регистре конфигурации дверей.

.cpp, 02.02.2004 12:04:13:

Balancer>Меняет. При сбое центарльного процессора в одной задаче (завис) откажет вся система, при сбое контроллера - откажет только один компонент системы.

Жаловался мне один знакомый - владелец маленького автосервиса. Сейчас производители автомобилей стремятся делать машины так, что бы по максимуму затруднить их обслуживание и ремонт в неспециализированных сервисах, повышая уровень компьютеризации автомобилей. При этом микроконтроллеры понатыканы повсюду - даже подъемом/опусканием стекол управляет отдельный компьютер в каждой двери, получая команды от центрального компьютера. Так вот один клиент этого автосервиса купил в Германии фольксваген (забыл какой), и на границе у него все стекла как опустились, так больше никак не поднимались. Пришлось мужику до самой Риги ехать "с ветерком". А дело было зимой, мороз -20С. А всех проблем - сброс флажков в регистре конфигурации дверей.

 

Ну и что это доказывает ?

Это очень четко подтверждает слова Balancer'а. Двигатель ведь завелся, значит система управлением вспрыском топлива не пострадала. А буде все на одном, так и движок не завелся бы, да и еще что-нибудь могло случится (не обязательно, но вероятно).

Centuriones, 02.02.2004 13:15:04:

Это очень четко подтверждает слова Balancer'а. Двигатель ведь завелся, значит система управлением вспрыском топлива не пострадала. А буде все на одном, так и движок не завелся бы, да и еще что-нибудь могло случится (не обязательно, но вероятно).

 

Теоретически такая проблема и на одном процессоре могла возникнуть. примитивный пример - ни у кого в виндах только одна софтина не зависала? Впрочем, такое возможно и без вытесняющей многозадачности. Как в кооперативной, так и вообще в однозадачных системах. Скажем, сбой в какой-лио проверке. Те же вышеупомянутые флаги какие-нибудь. Большая экзотика - сбой непосредственно в проверяющем коде.

В одном из округов проводили голосования, и из-за ошибки в программе СУБД было потеряно около 250 тыс. голосов - просто так - вжик, и нету.  Но самое убийственное в истории то, что они не стали проводить повторное голосование, потому что, слушайте сюда - эти 250 тыс. голосов уже не повлияли бы на исход выборов, был очевиден сильный разрыв между кандидатами.

 

Хе-хе. Одно время приходилось заниматься регистрацией акционеров на собраниях и обработкой результатов голосований. За два года ни на одном собрании окончательный пересчет в "домашних" условиях не совпал с оперативным, который и фиксировался в официальных документах. Но, там - легче, результат голосования обычно можно сказать и до начала собрания с точностью не хуже 0,5%

Balancer, 31.01.2004 12:55:58:

Меняет. При сбое центарльного процессора в одной задаче (завис) откажет вся система, при сбое контроллера - откажет только один компонент системы. Если он не важен для жизни аппарата или дублирован - можно будет продолжить работу дальше Я уже молчу про поышение надёжности. Хотя "контактов" и больше (что по идее снижает андёжность системы в целом), но система становится работоспособной при локальных повреждениях.

 

Не, Ром, ты подразумеваешь, что эти системы работают полностью независимо. Это не всегда так. И чаще не так. Давай посмотрим на проц, кэш и память - что называется сильно связанными системами - сбой в любой из них приводит к тому, что все летит.

Пример с БМВ - очень интересен. Поскольку системы были независимы, то такое проканало - при центральном проце тоже может проканать - как задача написана. А вот, в случае, если они зависимы - например, кислородный сенсор - работает сам по себе и данные тихонечко выдает, но, если центральный проц увидит, что он того - капут, то не завести вам современную машину. Хотя девайсы работают независимо (технически), в параллель, просто одно из устройств жизненно зависит от другого.

Ну так и взаимодействие протоколов интерфейсов модулей у нас же тоже программное.

 

И как это отменяет анализ взаимодействия модулей как черных или белых ящиков? В чем тут отличие программных модулей от аппаратных?

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

 

Так, пришло время разбираться с терминологией. Что ты понимаешь под асинхронным взаимодействием? Чует мой сердце, что скажешь ты - это возможность получать сообщения/прерывания/вызовы в произвольный момент времени. Этого не достаточно. Вызывающий процесс очень часто хочет знать результаты вызова - полная синхронизация. Посылающий сообщение, хочет знать получил ли коллега сообщение. Опять-таки хочет получить что-то в ответ - опять синхронизация.

Но, как я понял, это были пайпы на одном процессоре

 

Не обязательно. Зависит от операционки. Иногда привязывают процесс к конкретному процу для повышения эффективности. Например, NT так привязывает обработчики-драйвера сетевых карточек - они на этом у Линя выиграли как-то. Так что такая ситуация может возникнуть и на многопроцессорном компе.

Что же до обращения к общим переменным, которые упоминал Mishka - не должно их быть. Должно быть только интерфейсное взаимодействие.

 

А какая разница - ты передаешь параметром - на момень передачи копия может стать уже недействительной. Или ты защитишь ее семафорами/мониторами - та же Ж только в профиль. Кроме того, как ты передашь из такого асинхронного обработчика данные в программу/процесс? Он вызван ассинхронно - понятия не имеет о текущей среде выполнения. Понятия не имеет, может ли он что-то модифицировать и/или читать. Без общих переменных (в широком смысле) тебе не обойтись.

Ну так и как он тогда мог зависнуть из-за переполнения какой-то мелочи типа модуля флешпамяти?

 

А очень просто - как может NT зависнуть из-зи нехватки памяти - никогда не пробовал посмотреть на поведение ее при захвате реальной памяти и закреплении ее как не листаемой? Т.к. NT по-сути это micro-kernel реализация, то получается иногда, что системному модулю просто не хватает памяти и система приплывает.

Rada, 31.01.2004 04:45:47:

Ещё история, правда не из области космоса и военки, но тоже забавно (прочитал или в TIME или в Newsweek), причём технической детали происшествия я не знаю, а из-за иронии произошедшего. В одном из округов проводили голосования, и из-за ошибки в программе СУБД было потеряно около 250 тыс. голосов - просто так - вжик, и нету. Но самое убийственное в истории то, что они не стали проводить повторное голосование, потому что, слушайте сюда - эти 250 тыс. голосов уже не повлияли бы на исход выборов, был очевиден сильный разрыв между кандидатами. Вот так-то - а говорят - каждый голос важен. Короче, вот этим горе-программистам и ноги поотрывать не мешало бы. Вообще, удивляет раздолбайсво в проведении выборов - взламывай что хочешь, никаких дупликаций на бумаге тебе, ничего.

 

Ну, если такую ошибку обнаружили, то где гарантия, что еще голосов не потеряли?

Rada, 31.01.2004 04:45:47:

никаких дупликаций на бумаге тебе, ничего.

 

А меня всегда это удивляло - как бумаго-то может гарантировать от чего-то? Выборы анонимные, бумага чаще всего обычная. Запасные билеты есть. Как показывает опыт - мухлежа не меньше - даже со специальной бумагой. Да - выборы-то, как правило, анонимные - никаких подписей. Объясните мне - где тут правда?

Centuriones, 02.02.2004 13:15:04:

Это очень четко подтверждает слова Balancer'а. Двигатель ведь завелся, значит система управлением вспрыском топлива не пострадала. А буде все на одном, так и движок не завелся бы, да и еще что-нибудь могло случится (не обязательно, но вероятно).

 

Можно по-подробней про доказательство? В ответе Роману я упомянул по O2 сенсор - это мы куда отнесем? А работу проца, который управляет тормозами - если он откажет, то мы все равно заведем машину и даже ехать сможем, только каблуки придется менять каждый километр.

Так если он хочет знать результат - нехай ждет сколько-то времени ответное сообщение а потом выпадает по таймауту. И конечно вычислительный и канальный уровни по выполнению развязать - прием-передача сообщений отдельно, основной цикл вычислений - отдельно. То есть в основном цикле - флажки - если флажок установился - обработать пришедшее сообщение. если нет - пропускаем. А устанавливать - обработчиком прерывания по приему. Например.

Потом, связность системы по определению должна быть минимально необходимой - то есть в данном примере управление АКП, контроль CO2 и зажигание - это один управляющий модуль - контроль двигателя называется

Mishka

Я имел ввиду:

.cpp, 02.02.2004 12:04:13:

Balancer>Меняет. При сбое центрального процессора в одной задаче (завис) откажет вся система, при сбое контроллера - откажет только один компонент системы.

Жаловался мне один знакомый - владелец маленького автосервиса. Сейчас производители автомобилей стремятся делать машины так, что бы по максимуму затруднить их обслуживание и ремонт в неспециализированных сервисах, повышая уровень компьютеризации автомобилей. При этом микроконтроллеры понатыканы повсюду - даже подъемом/опусканием стекол управляет отдельный компьютер в каждой двери, получая команды от центрального компьютера. Так вот один клиент этого автосервиса купил в Германии фольксваген (забыл какой), и на границе у него все стекла как опустились, так больше никак не поднимались. Пришлось мужику до самой Риги ехать "с ветерком". А дело было зимой, мороз -20С. А всех проблем - сброс флажков в регистре конфигурации дверей.
 

 

Как раз hcube про СО2 так хорошо сказал. Опередил. Если я правильно понял, то как раз решающее значение имеет связность. Хотя мне рассказывали, что в некоторых машинах с места не стронешься, пока дверь не закроешь, но это уже техника безопасности.

Вообще конфликты, захваты ресурсов, когда они должны быть свободными - очень неприятная вещь. Не знаю как в Windows NT Х.ХХ, не работал, а в 9Х частенько подобные фокусы выводят из себя. Когда после работы с документом начинаешь по необходимости перемещать файл, а тебе в ответ - "Пшел вон, файл занят!" - так и хочется запустить чем-то тяжелым в монитор, так как надо перегружаться. Понятно, Windows - не система управления космическим аппаратом, но это явное несовершенство.

Кстати (немножко не в тему), читая эту тему начинаешь лучше понимать роль пилотируемой космонавтики и пилота в истребителе.

hcube, 02.02.2004 19:31:21:

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

 

Так это и есть синхронизация. Т.е. просто асинхронной передачи данных недостаточно на все случаи жизни.

И конечно вычислительный и канальный уровни по выполнению развязать - прием-передача сообщений отдельно, основной цикл вычислений - отдельно. То есть в основном цикле - флажки - если флажок установился - обработать пришедшее сообщение. если нет - пропускаем. А устанавливать - обработчиком прерывания по приему. Например.

 

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

Потом, связность системы по определению должна быть минимально необходимой - то есть в данном примере управление АКП, контроль CO2 и зажигание - это один управляющий модуль - контроль двигателя называется

 

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

Centuriones, 03.02.2004 02:54:07:

Как раз hcube про СО2 так хорошо сказал. Опередил. Если я правильно понял, то как раз решающее значение имеет связность. Хотя мне рассказывали, что в некоторых машинах с места не стронешься, пока дверь не закроешь, но это уже техника безопасности.

Вообще конфликты, захваты ресурсов, когда они должны быть свободными - очень неприятная вещь. Не знаю как в Windows NT Х.ХХ, не работал, а в 9Х частенько подобные фокусы выводят из себя. Когда после работы с документом начинаешь по необходимости перемещать файл, а тебе в ответ - "Пшел вон, файл занят!" - так и хочется запустить чем-то тяжелым в монитор, так как надо перегружаться. Понятно, Windows - не система управления космическим аппаратом, но это явное несовершенство.

Кстати (немножко не в тему), читая эту тему начинаешь лучше понимать роль пилотируемой космонавтики и пилота в истребителе.

 

Я бы сказал дизайн. Дизайн должен быть таковым, чтобы система могла надежно выполнять свои функции.

Я пытаюсь отделить мух от котлет - наличие однопоточности и многопоточности это немного другое нежели чем модульность. Да, многопоточность это другой уровень. Но, строгое ИМХО, она позволяет решать задачи более высокого уровня сложности - именно по взаимодействию параллельно работающих модулей. А далее, если есть взаимодействие, то в однопоточной системе вроде все проще - т.к. поочереди обрабатываются, но при этом слов в одном месте приводит с слому всего. В многопоточности немного с этим легче, но сложнее со взаимодействием.

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

Кстати, иногда люди тоже в клинч впадают. Помните эту сценку, когда Иван Кузмич с кем-то там еще в одну дверь у классика проходили (пардон, не помню точно имен)?