Гради Буч - Объектно-ориентированный анализ и проектирование с примерами приложений на С++ (1158635), страница 70
Текст из файла (страница 70)
Определив этифункции как чисто виртуальные, мы передали ответственность за ихконкретную оптимальную реализацию классам, производным от Queue.Ранее отмечалось, что одна из основных задач наших архитектурныхрешений заключается в том, чтобы дать возможность клиенту копировать,присваивать и проверять на равенство экземпляры абстрактного базовогокласса, даже если они имеют различное представление.
Эта возможностьдостигается за счет использования итераторов и некоторых служебныхфункций, позволяющих просматривать структуры независимо от ихпредставления. Например, оператор присваивания для класса Queue можноопределить следующим образом:template<class Item>Queue<Item>& Queue<Item>::operator=(const Queue<Item>& q){if (this == &q)return *this;((Queue<Item>&)q).lock();purge();QueueActiveIterator<Itea> iter(q);while (!iter.isDone()) {add(*iter.currentltem());iter.next();} ((Queue<Item>&)q).unlock();return *this;}В данном алгоритме используется идиома блокирования, котораяболее подробно рассмотрена в следующем разделе.Присваивание осуществляется в порядке просмотра активнымитератором структуры, определяемой аргументом q.
Сначала защищеннаяслужебная функция purge очищает очередь, а затем к ней с помощью другойзащищенной служебной функции add последовательно добавляются новыеэлементы. Тот факт, что процесс итерации осуществляется с помощьюполиморфных функций, дает возможность копировать, присваивать ипроверять на равенство объекты, имеющие одинаковую структуру, но сразными представлениями.Пассивный итератор, который также называют аппликатором,характеризуется тем, что он применяет определенную функцию к каждомуэлементу структуры. Для класса Queue пассивный итератор можно определитьследующим образом:template <class Item>class QueuePassiveIterator {Public:QueuePassiveIterator(const Queue<Item>&);~QueuePassiveIterator();int apply(int (*)(const Item&));Protected:const Queue<Item>& queue;};Пассивный итератор действует на все элементы структуры за(логически) одну операцию.
Таким образом, функция apply последовательнопроизводит одну и ту же операцию над каждым элементом структуры, покапередаваемая итератору функция не возвратит нулевое значение или пока небудет достигнут конец структуры (в первом случае функция apply самавозвратит нулевое значение в знак того, что итерация не была завершена).СинхронизацияПри разработке любого универсального инструментального средствадолжны учитываться проблемы, связанные с организацией параллельныхпроцессов. В операционных системах типа UNIX, OS/2 и Windows NTприложения могут запускать несколько "легких" процессов26.
В большинствеслучаев классы просто не смогут работать в такой среде без специальнойдоработки: когда две задачи взаимодействуют с одним и тем же объектом, онидолжны делать это согласованно, чтобы не разрушить состояния объекта. Какуже отмечалось, существуют два подхода к задаче управления процессами;они находят свое отражение в существовании защищенной исинхронизированной форм класса.При разработке данной библиотеки было сделано следующеепредположение:разработчики, планирующие использовать параллельные процессы,должны импортировать либо разработать сами по крайней мере классSemaphore (семафор) для синхронизации легких процессов.
Разработчики,которые не хотят связываться с параллельными процессами, будут свободныот необходимости поддерживать защищенные или синхронизованные формыклассов (таким образом, не потребуется никаких дополнительных издержек).Защищенные и синхронизированные формы изолированы в библиотеке иосновываются на своей внутренней реализации параллелизма.
Единственнаязависимость от локальной реализации сосредоточена в классе Semaphore,который имеет следующий интерфейс:class Semaphore {public:Semaphore ();Semaphore (const Semaphore&);Semaphore (unsigned int count);~Semaphore ();void seize(); // захватить void release(); // освободитьunsigned int nonePending() const;protected:};Так же, как и при управлении памятью, мы разделяем политикусинхронизации процессов и ее реализацию. По этой причине в аргументышаблона для каждой защищенной формы включен класс Guard (страж),ответственный за связь с локальной реализацией класса Semaphore или егоэквивалента.
Аргументы шаблона для каждой из синхронизированных формсодержат класс Monitor, который близок по своим функциональнымсвойствам к классу Semaphore, но, как будет видно в дальнейшем,обеспечивает более высокий уровень параллелизма процессов.Как показано на рис. 9-3, защищенный класс является прямымподклассом своего конкретного ограниченного либо неограниченного класса исодержит в себе объект класса Guard.
Все защищенные классы имеютобщедоступные функции-члены seize (захватить) и release (освободить),позволяющие получить эксклюзивный доступ к объекту. Рассмотрим вкачестве примера класс GuardedUnboundedQueue, производный отUnboundedQueue:template<class Item, class StorageManager, class Guard>class GuardedUnboundedQueue : public UnboundedQueue<Item,StorageManager> {public:GuardedUnboundedQueue ();virtual ~GuardedUnboundedQueue ();virtual void seize();virtual void release();protected:Guard guard;};В нашей библиотеке предусмотрен интерфейс одного изпредопределенных классов защиты: класса semaphore.
Пользователи могутдополнить реализацию данного класса в соответствии с локальнымопределением легкого процесса.На рис. 9-10 приведена схема работы данного вариантасинхронизации; клиенты, использующие защищенные объекты, должныпридерживаться простого алгоритма: сначала захватить объект дляэксклюзивного доступа, провести над ним нужную работу, и после ееокончания снять защиту (в том числе в тех случаях,Рис. 9-10. Процессы защищенного механизмакогда возникла исключительная ситуация).
Другая схема поведениярассматривается как социально неприемлемая, поскольку претензии одногоагента не позволят правильно работать другим. Если мы, например, не снимемзащиту после окончания работы с объектом, больше никто не сможетполучить к нему доступ; попытка снятия защиты с объекта, к которому вданный момент никто не имел эксклюзивного доступа, также может привестик нежелательным последствиям. Игнорирование этого протокола простобезответственно, поскольку оно может разрушить состояние объекта, скоторым одновременно работают несколько агентов.Основное преимущество защищенной схемы - ее простота. В то жевремя для агентов, производящих операции над одним и тем же объектом,использование данной модели обуславливает необходимость выполненияопределенных коллективных действий.
Другая особенность защищенныхформ состоит в том, что она дает возможность агентам выделять критическиважные моменты, когда несколько операций, произведенных над объектом,будут гарантированно интерпретироваться как одна атомарная транзакция.Подобно механизму управления памятью, сигнатура шаблоназащищенной формы импортирует стража, а не превращает его внеизменяемую характеристику. Это позволяет пользователям ввести новуюполитику синхронизации. При использовании в качестве стражапредопределенного класса Semaphore, стандартная политика синхронизацииподразумевает, что каждому объекту ставится в соответствие свой семафор.Данное решение приемлемо только до тех пор, пока количество параллельныхпроцессов не достигнет некоторого критического значения.Альтернативный подход подразумевает возможность обслуживанияодним семафором сразу нескольких защищенных объектов.
Разработчику приэтом нужно только создать новый класс-страж, имеющий тот же протокол, чтои semaphore (но не обязательно являющийся его подклассом). Этот классможет содержать семафор в качестве статического члена; тогда семафор будетсовместно использоваться всеми экземплярами класса. Инстанцируязащищенную форму с этим новым стражем, разработчик библиотеки вводитновую политику, поскольку все объекты инстанцированного классапользуются общим стражем, вместо выделения отдельного стража каждомуобъекту. Преимущество данной схемы наиболее ясно проявляется, когдановый класс-страж используется для инстанцирования других структур:все полученные объекты будут работать с одним и тем же стражем.Таким образом, на первый взгляд незначительное изменение политикиприводит не только к уменьшению количества параллельных процессов, нотакже позволяет клиенту блокировать целую группу объектов, несвязанныхнапрямую.
Захват одного объекта автоматически блокирует доступ и ко всемостальным структурам, имеющим того же стража, даже если это структурыразличного типа.Синхронизированный класс, являясь прямым подклассом какого-либоконкретного ограниченного или неограниченного класса, содержит в себеобъект-монитор, протокол которого можно описать следующим абстрактнымбазовым классом:class Monitor {public:Monitor();Monitor(const Monitor&);virtual ~Monitor();virtual void seizeForReading() = 0;virtual void seizeForWriting() = 0;virtual void releaseFromBeadingt() = 0;virtual void releaseFromWritingt() = 0;protected:…};С помощью мониторов можно реализовать два типа синхронизации:• ОдиночнаяГарантирует семантику структуры вприсутствии нескольких потоков управления, но с одним читающим илиодним записывающим.• МножественнаяГарантирует семантику структуры вприсутствии нескольких потоков управления, с несколькими читающими илиодним записывающим.Агент записи меняет состояние объекта; агенты записи вызываютфункции-модификаторы.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
