3 Реализация
В качестве средства реализации для эмуляции продолжений был выбран Stackless Python, предоставляющий ряд возможностей, позволяющих как нельзя лучше решить эту задачу, по крайней мере, для тех целей, которые необходимо достичь в рамках данной работы.
3.1 Stackless Python
Stackless Python является расширенной версией языка программирования Python. Он создан с целью помочь программистам использовать все возможности разработки, основанной на потоках, кроме повышения производительности за счет распараллеливания выполнения задач[7]. Взамен Stackless избавляет разработчиков от сложностей, связанных с использованием обычных потоков. Для решения этой задачи Stackless дополняет Python следующими возможностями:
Тасклеты (англ. tasklets) позволяют «оборачивать» функции для того, чтобы исполнять их в микропотоках. Тасклеты являются легковесными и широко портируемыми, что позволяет им быть превосходной альтернативой системным потокам и процессам.
Каналы (англ. channels) используются для двустороннего обмена данными между тасклетами. Каналы не содержат данных, а лишь позволяют текущему тасклету ставить данные в очередь следующему получающему тасклету. При отправке данных через канал тасклет, ожидающий данных из этого канала, получает их и возобновляет работу. Если получателя не существует, то тасклет блокируется очередью канала. Точно так же осуществляется сообщение и в обратном направлении.
Планирование (англ. scheduling) осуществляется с помощью встроенного планировщика, работающего по алгоритму Round Robin. При создании нового тасклета он автоматически прикрепляется к концу списка планировщика, который специальным вызовом переключает задачи, пока список не окажется пуст.
Сериализация (англ. serialization) – ключевая возможность, благодаря которой становится возможным сохранять на диск и загружать тасклеты для продолжения вычислений с того места, на котором тасклет был сериализован.
3.2 Система управления продолжениями
Основная идея заключается в следующем (см. Рисуноки 9, 10). Управляющая компонента системы запускается в отдельном микропотоке. В ее задачи входит инициализация управляющих структур и получение запроса. При получении запроса управляющая компонента в первую очередь пытается получить идентификатор продолжения. В зависимости от результата этой операции система либо совершает попытку извлечь из хранилища продолжение, либо определяет функцию-обработчик, которой нужно передать управление и «заворачивает» ее в новый тасклет. При нормальном выполнении этих действий система получает тасклет, который вставляет в очередь и переключается на него.
Ввиду того, управляющая компонента отвечает за получение запроса и возврата ответа, переключение между тасклетами управляющей компоненты и тасклетом функции-обработчика осуществляется с помощью канала: ответ функции-обработчика посылается через канал от обработчика системе. Таким образом, при вставке системой тасклета функции-обработчика в очередь планировщика следующим действием ее должно быть ожидание данных из канала.
Функция-обработчик, получив управление, таким образом, выполняет действия по обработке пришедших данных, а затем с помощью вызова функции API посылает в канал результат обработки.
Управляющая компонента получает результат обработки и возвращает его клиенту, перед этим сохранив состояние тасклета функции-обработчика в хранилище продолжений.
Рисунок 9. Диаграмма сообщения управляющей компоненты
системы и функции-обработчика
3.3 Хранилище продолжений
Сохраненные продолжения, как описано выше, образуют структуру в виде «леса». Способ хранения этой структуры играет важную роль в целостности, безопасности и скорости работы системы. Поэтому в зависимости от реализации системы в целом было решено описать хранилище как абстрактный класс, а конкретизации его создавать фабрикой. Класс «Хранилище» должен уметь создавать, сохранять и восстанавливать объекты конкретной реализации абстрактного типа «Состояние». Этот абстрактный класс задает интерфейс для системы, который позволяет ей получить узел конкретного «дерева продолжений» с указанием времени создания и ссылкой на «родителя». Подобная абстракция позволяет использовать в качестве хранилища как память, так и базу данных и файловую систему (см. Рисунок 10).
Рисунок 10. Диаграмма классов организации хранилища продолжений
Стоит отметить, что для многопотокового сервера хранилище продолжений можно организовать непосредственно в памяти, к которой имеется доступ у каждого потока. В случае же распределенного сервера необходимо выбрать альтернативный способ хранения продолжений в общем для всех процессов пространстве. Необходимо также учитывать ограниченное «время жизни» продолжений. Необходимо обеспечить хранилище продолжений механизмом, позволяющим обеспечивать актуальность хранящихся в нем состояний.
Для использования хранилища в распределенном сервере разумно использовать memcached. Это система кэширования различных объектов в оперативной памяти, которая позволяет, используя специальное API, сохранить в ОЗУ блок данных, сопоставленный с определенным ключом – в случае хранилища продолжений это идентификатор продолжения. Следует отметить, что для каждого объекта, сохраненного в memcached, устанавливается «время жизни», что обеспечивает для хранилища продолжений реализацию еще одного его требования.
Также для использования хранилища в многопроцессном режиме можно использовать базу данных. Хранилище в таком случае будет организовано как таблица с четырьмя полями (см. Рисунок 11). При обращении к записи в таблице по идентификатору необходимо проверять актуальность выбранного состояния. Если «время жизни» выбранного состояния истекло, необходимо по связям добраться до корня «дерева продолжений», которому принадлежит выбранное состояние, а затем это дерево удалить.
Рисунок 11. Таблица сохраненных состояний
Нетрудно заметить, что удаление «устаревших» состояний требует множество операций, производимых над таблицей, что увеличивает нагрузку на сервер СУБД и снижает производительность системы в целом.
В следствие того, что сохраненное состояние занимает сравнительно большой объем памяти актуализация хранилища состояний описанным выше способом является неоптимальной, т.к. требует достаточного большого «времени жизни» для состояния. Другое решение заключается в перестройке дерева таким образом, чтобы удалялись исключительно те состояния, «время жизни» которых истекло. Этот подход позволяет минимизировать объем памяти, используемой для хранения состояний, но является неоптимальным по производительности, поэтому применять его нужно в том случае, когда хранилище организованно в оперативной памяти.
|
