Конференции ИВТ СО РАН

Тезисы докладов

Информационные технологии

Идея реализации возникла при работе над системой, выполняющей большое количество асинхронных операций над относительно большим (около сорока) числом объектов, работающих в разных потоках. Для централизации передачи информации о событиях в системе использовалась общая очередь сообщений. Некоторые сообщения, в частности информирующие о критических ошибках выполнения, требуют особой обработки: например, переключения объекта или подсистемы в режим восстановления после сбоя. Асинхронная работа при этом становится одним из возможных источников проблем, так как очередь может содержать сообщения, отправленные еще в рабочем режиме. Попытка обработать их после того, как фактически произошел сбой, приведет к непредсказуемым последствиям.

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

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

Функциональные возможности:

1. Три типа действий, на которые можно назначить триггер: добавление в очередь элемента, удаление (без передачи далее) или извлечение объекта.
2. Аналогичные действия на срабатывание триггера: добавление элемента в очередь, удаление объектов из очереди, передача объекта на извлечение (в простейшем случае - перемещение в начало очереди). Один триггер может осуществлять несколько разных действий в фиксированной последовательности.
3. Возможность указать фиксированное число срабатываний триггера или сделать его перманентным.
4. Различные варианты сравнения объектов с шаблоном триггера: сравнение по адресу, сравнение с использованием виртуальных методов класса шаблона и сравнение с привлечением пользовательской функции.
5. Создание триггеров общего назначения, контролирующих всю очередь, или привязка триггера к конкретному сообщению.
6. Предварительное накопление изменений, вносимых в очередь, в буфере, что позволяет отменить в экстренных случаях все вызванные триггерами действия.

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

Литература

1. Рихтер Дж. Windows для профессионалов: создание эффективных Win32-приложений с учетом специфики 64-разрядной версии Windows / Пер. с англ. - СПб: Питер, 2003.
2. Гамма Э., Хелм Р., Джонсон м., Влиссидес Дж. Приемы объектно-ориентированного проектирования. Паттерны проектирования / Пер. с англ. - СПб: Питер, 2004.

Примечание. Тезисы докладов публикуются в авторской редакции

Ваши комментарии Обратная связь

[Головная страница] [Конференции]

© 1996-2000, Институт вычислительных технологий СО РАН, Новосибирск
© 1996-2000, Сибирское отделение Российской академии наук, Новосибирск