Windows XP / 7 .

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

Решение, предлагаемое в данной статье, основано на представлении активного объекта как конечного автомата, имеющего набор состояний, причем за один шаг активный объект выполняет короткое действие, которое может изменить состояние автомата или оставить автомат в том же состоянии. Кооперативная многозадачность предполагает, что ответственность за диспетчеризацию параллельных процессов (активных объектов) несет программист, и справедливое распределение процессорного времени требует, чтобы каждый шаг активного объекта был коротким и не был связан с непредсказуемыми временными задержками. Другое требование к шагу объекта связано с транзактностью - после каждого шага объект должен находиться в непротиворечивом состоянии и должен полностью завершить изменение своего состояния. "Оживление" всех активных объектов приложения происходит в бесконечном цикле, на каждой итерации которого выполняется шаг очередного активного объекта.

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

Админ

* описание жизненного цикла активного объекта;
* изменение состояния активного объекта;
* управление жизнью всех активных объектов в контексте отдельной нити.

В целом, функциональность активного объекта соответствует функциональности нити или класса Thread. Объект может быть активным или неактивным. В активном состоянии его жизненный цикл определяется методом Step. Установка свойства Active изменяет активность объекта. Методы Sleep деактивируют объект на указанный интервал времени или до вызова WakeUp. Свойство Sleeping возвращает истинное значение, если объект находится в состоянии ожидания. Диспетчеризацию (циклический обход всех активных объектов и вызов у каждого активного объекта метода Step), инициирует статический метод Open. Он открывает театр жизненных драм всех активных объектов приложения, а метод Close его закрывает.

Админ

Как уже было сказано, активный объект реализуется как конечный автомат. Простейшая, классическая реализация автомата использует целочисленную переменную состояния (state) и оператора выбора (switch).

Основная идея состоит в том, что каждое состояние автомата описывается методом-делегатом, причем смена состояния приводит к смене делегата.

Во второй версии C# появился весьма удобный метод реализации итераторов [5]. Оператор yield return выполняет мягкий возврат очередного значения итератора, подобно тому, как это происходит в сопрограммах, но реализуется он через конечный автомат. Заглянув в код, генерируемый компилятором, можно увидеть, что компилятор создает скрытый класс, реализующий интерфейс IEnumerator, целочисленное поле state и метод MoveNext, содержащий табличный оператор switch. То есть, реализация yield в точности соответствует классическому конечному автомату. Поскольку оператор yield return можно применять только в итераторах, потребуется немного изменить сигнатуру метода Step.

Часть класса, которая управляет активностью объекта, довольно проста.

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

static ActiveObject()
{
dispatcher = new Dispatcher();
timer = new Timer();
activator = new Activator();
log = new Log();
}

Админ

Диспетчер представляет собой список объектов, находящихся в активном состоянии. Реализация диспетчера основана на двусвязном списке с явно выделенными граничными узлами first и last. Связи активного объекта с предыдущим и последующим хранятся в приватных полях prev и next. Некоторая сложность списка обусловлена тем, что активный объект может во время своего выполнения создать новый активный объект, активировать или деактивировать другой объект, или деактивировать самого себя. То есть, состояние списка может измениться при его обходе.

Админ