Программное обеспечение и его разработка
Шрифт:
Если в состав многопроцессорного комплекса входят машины в 1 МКС — каждая из них выполняет миллион команд в секунду — и у нас их четыре, мы, конечно же, получим систему в 4 МКС, не так ли? Нет, не так. Когда сразу несколько ЦП пытаются обратиться к одному блоку памяти, возникает эффект блокирования. В некоторых приложениях специально формулируются требования по синхронизации, позволяющие достичь целостности данных, когда несколько ЦП пытаются обратиться к одному файлу данных или к одной физической ячейке памяти. При этом может возникать некоторое снижение производительности, измерить которое и понять очень сложно. (См. рис. 7.1.)
Если кто-то говорит, что такая-то и такая-то системы имеют по 16 ЦП, можно побиться об заклад, что либо 1) они работают с очень специальной задачей в крайне жестких граничных условиях, либо 2) такие системы не более чем любопытная лабораторная диковина, которая вряд ли может быть применена в настоящих приложениях. На путях внедрения 16-процессорных систем в практику универсальной обработки данных еще остается много препятствий.
Существуют, однако, и замечательные примеры применения многопроцессорных систем в системах реального времени. Система диспетчеризации авиалиний FAA имеет четыре процессора, четыре программируемых канала ввода/вывода и несколько десятков отдельных блоков памяти. В качестве многопроцессорной системы она начала работать более шести лет назад в 21 центре. Это очень дорогостоящая разработка, причем средства защиты от отказов (продолжения работы в более ограниченных условиях, когда часть аппаратуры отключается) еще до конца не запрограммированы. Но многопроцессорная обработка уже ведется.
До появления многопроцессорной обработки надежность системы гарантировалась с помощью дублирования — две одинаковые системы ставились бок о бок, и каждая из них выполняла все задание целиком. Этот метод применялся в десятках систем и работал весьма удовлетворительно. И в военно-воздушных силах — в системе раннего оповещения о появлении баллистических ракет, — и в большинстве систем NASA по освоению космического пространства в начале 1960-х г. с успехом применялся этот метод. Его используют и сейчас, но доля его в общем числе разработок намного снизилась.
Почему? Какой же недостаток можно усмотреть в таком способе обеспечения работоспособности? В основном стоимость. Ведь дублирующая система фактически не работает до тех пор, пока не выведена из строя основная.
Для того чтобы определить, что надежнее — дублирование или многопроцессорность, разберем простой пример. Для простоты рассмотрим случай многопроцессорной системы всего с двумя блоками памяти и двумя ЦП, не обращая внимания на каналы ввода/вывода и другие детали. (См. рис. 7.2.) Единственная разница между системами состоит в том, что устройства памяти разделяются обоими процессорами (доступны им обоим). Следовательно, потеря одного ЦП в системе 1 и одного блока памяти в системе 2 не должна приводить к прекращению функционирования. Теперь нам надо представить себе, что мы хотим определить вероятность готовности системы к продолжению работы.
Нам надо принять во внимание среднее время между отказами для каждого устройства и вероятность одновременных отказов, учесть надежность дополнительных цепей, управляющих переключением с одного устройства на другое, а также среднее время ремонта каждого элемента системы.
Интуитивно может показаться очевидным, что многопроцессорная система имеет более высокий коэффициент готовности, но это не так, по крайней мере не всегда так. Нужно обязательно провести исследование и расчеты, очень длительные расчеты. В 1963 г. глубокое изучение этого вопроса, проведенное исследовательской группой IBM, созванной В. Пирсоном (вице-президент IBM, а затем председатель отделения) для того, чтобы ответить на запрос, поступивший из FAA, привело к созданию системы диспетчеризации авиалиний Соединенных Штатов.
Технический отдел IBM горячо доказывал, что в данном случае дублирование даст более хороший результат, система будет в более высокой степени готовности. В качестве предполагаемого руководителя выполнением заказа для FAA я спорил с ними, доказывая, что многопроцессорный вариант более надежен (исходные требования от FAA прямо приводили к многопроцессорной
системе). Многие часы провели мы в исследовательском комитете. К моему удивлению, было выработано решение, в котором система с дублированием объявлялась более надежной. В тот зимний день 1963 г., проведенный в Поукипси, шт. Нью-Йорк, я просто отказывался верить своим ушам. Лирсон склонялся к тому, чтобы в IBM делали систему с дублированием. «Но ведь требования прямо ведут к многопроцессорности!» По некоторым причинам я никак не мог объяснить это Лирсону. Он спросил, все ли собравшиеся согласны с тем, что в требованиях есть предпосылки многопроцессорной системы. Все были согласны. Лирсон решил остановиться на многопроцессорном варианте. Наш проект был принят.Многопроцессорная обработка обусловлена тремя главными причинами — две из них довольно простые, третья же очень сложна.
Прежде всего многопроцессорность увеличивает мощность (пропускную способность) на самом высоком уровне производительности, достигнутом вычислительной техникой. Если мы не способны построить более быструю вычислительную машину, мы можем объединить в одной конфигурации два ЦП.
Вторая причина состоит в возможности обеспечить безболезненный рост, не требуя дополнительного пространства, не срывая работ, мы получаем возможность увеличивать вычислительную мощность, убирая один из ЦП и заменяя его другим, более мощным и совместимым по программному обеспечению.
Третья причина заключается в необходимости обеспечить бесперебойную работу. Не просто защиту от отказов, а именно бесперебойную работу. Простая защита от отказов приводит к тому, что для каждого критичного устройства в систему включается еще одно резервное, и если происходит отказ, то к линии подключается резерв, а работа продолжается. Бесперебойная работа подразумевает наличие нескольких способов обработки кризисных ситуаций, используя в качестве резерва несколько ЦП и блоков памяти и исключая из системы после каждого очередного отказа некоторую часть выполняемых ею функций. Аппаратура для бесперебойной работы проще, а вот программное обеспечение построить для нее практически невозможно. Количество комбинаций возможных в системе отказов очень быстро становится огромным. Обработать программными средствами один отказ в памяти не очень сложно, но, если сразу же может возникнуть второй отказ, третий, мы тут же сталкиваемся с сотнями различных комбинаций, и в программах нужно отражать их все. Очень скоро программа восстановления становится бесконечно большой. Если мы остановимся только на одном уровне резервирования, как при простой защите, это еще вполне выполнимо. Если же нам требуются два уровня, на которых придется осуществлять защиту, а в нашем распоряжении десятки разных устройств, каждое из которых подвержено отказам, перед нами встает уже гораздо более сложная задача.
Если я пользуюсь своим банковским счетом один и у меня есть несколько чеков, суммы которых я должен вычесть из суммы своего вклада, вычисленной накануне, я могу сделать это последовательно на одной машине. Но, если у меня два чека, один находится у вас, а другой я должен обработать сам, нам никак нельзя делать это одновременно, находясь за разными терминалами и по отдельности вычисляя новую сумму, иначе мы получим неверные результаты.
Предположим, что на моем счете находится 575 долларов и у меня есть чек на 35 долларов, а у вас — на 100 долларов. Если баланс начну подводить я, то, увидев сумму 575 долларов, я должен буду производить вычитание из нее. Если в это же время вы тоже начнете производить вычитание из этой же суммы, мы ошибемся. Я получу результат в 500 долларов, а вы в 475 долларов. Кто бы ни написал в основной файл новое значение последним, он напишет неверное значение. В данном случае не была обеспечена целостность процесса. Мы не имеем права разрешать внесение изменений в основной файл более чем одному пользователю за раз. Значение баланса должно быть заблокировано все время, пока кто-то его изменяет. Это справедливо и для многих других типов данных — мест расположения самолетов, медицинских сведений и т. д. Это же относится и к сложным вычислительным комплексам. Мы должны следить за целостностью данных и в многопроцессорных системах, и в системах распределенной обработки данных, и в сетях.