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

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

5.5.2. Самозащита с помощью межзадачных протоколов

Поскольку задачи являются автономными объектами, невозможно всегда с полной уверенностью гарантировать, что вызываемая задача получила адресованное ей сообщение. Рассмотрим рис. 5.22, на котором изображен межзадачный диалог.

Отправитель Адресат

Риг. 5.22. Простой способ передачи сообщений между задачами.

Такой диалог может возникнуть, например, между задачей-клиентом и пакетом MAIL ROOM, функционирование которого обсуждалось ранее. Предположим, что отправитель сообщения не получил на него ответа. Это может произойти по следующим причинам:

• сообщение не дошло до задачи-адресата; задача-адресат больше не существует (возможно, потому, что она выполнялась процессором, который вышел из строя);

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

• существует ошибка в задаче, которой адресовано сообщение.

Все эти причины вполне вероятны, кроме первой, которая нереальна вследствие физической сущности самого механизма рандеву; возврат из процедуры вызова входа SEND свидетельствует о получении сообщения адресатом. В этом смысле механизм рандеву является более надежным, чем просто передача сообщения, например, через общую память с помощью почтового ящика электронной почты.

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

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

Хотя создается впечатление, что механизм рандеву исключает необходимость применения протокола управления передачей сообщений, которые могут не дойти до получателя, это в какой-то части является чистой иллюзией. Чтобы убедиться в этом, достаточно вспомнить гл. 3 и 4, где отмечалось, что часто оказывается необходимым использовать задачу-посредник между отправителем и получателем, которая играет роль курьера, доставляющего сообщения, или обеспечивает их хранение. Если даже все рандеву, используемые при взаимодействии между двумя исходными задачами и задачей-посредником, являются абсолютно надежными, сообщения все же могут не дойти до адресата. Должны ли мы в связи с этим беспокоится о протоколах на уровне Ада-программ? Ответ будет зависеть от конкретных возможностей и аппаратного окружения целевой вычислительной системы.

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

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

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

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

Сущность такого подхода применительно к программному уровню проиллюстрирована на рис. 5.23 на примере взаимодействия отправителя и адресата (рис. 5.22) в предположении, что отправитель и адресат располагаются в разных узлах надежности. Активный коммуникационный пакет в каждом узле надежности служит для организации пересылки обращений к входам задач, принадлежащих другим узлам надежности. Отправитель должен использовать этот пакет для того, чтобы вызывать вход SEND задачи адресата. Коммуникационный пакет адресата выполнит затем требуемый вызов (возможно, путем порождения задачи-партнера) и передаст уведомление о завершении рандеву; до тех пор пока это уведомление не будет получено, отправитель будет находиться в заблокированном состоянии. В об-