Алгоритм параллельной сборки мусора представлен в [Dijkstra 1978]. Проблемы производительности подобных алгоритмов рассматривал [Cohen 1984]. Сборка мусора поколений представлена в [Ungar 1984].
Механизм сборки мусора ISE's среды, описанный в конце этой лекции, был создан Рафаэлем Манфреди (Raphael Manfredi) и усовершенствован Ксавьером Ле Вурч (Xavier Le Vourch) и Фабрис Францески (Fabrice Franceschi) (чей технический отчет служил основой данного здесь описания).
Упражнения
У9.1 Модели создания объектов
При обсуждении автоматического управления памятью рассмотрен подход, основанный на создании внутренних списков свободной памяти. В этом случае память, занимаемая утилизированными объектами, не возвращается операционной системе, а остается в создаваемом списке. Разработайте модель системы, демонстрирующую постоянный рост занимаемой памяти, хотя фактически требуемая приложению память ограничена.
Вы можете описать эту модель как последовательность о1, о2, о3,..., где оi либо 1, (что показывает выделение памяти одному объекту), либо (-n), показывающее восстановление n единиц памяти.
У9.2 Какой уровень утилизации?
Подход на уровне компонентов, если программировать на языке типа Pascal или C, где операционная система предоставляет dispose или free, может напрямую использовать эти операции вместо создания своего списка свободной памяти для каждого типа структур данных. Рассмотрите плюсы и минусы двух подходов.
У9.3 Совместное использование стека достижимых элементов
(Это упражнение подразумевает знакомство с результатами лекции 18) Перепишите компонент available, задающий стек достижимых элементов при подходе на уровне компонентов. Единственный стек должен совместно использоваться всеми связными списками одного и того же типа. (Указание: используйте функцию once.)
У9.4 Совместное использование
(Это упражнение подразумевает, что вы выполнили предыдущее и прочитали все лекции, включая лекцию 18) Можно ли сделать available стек разделяемым всеми связными списками произвольных типов?
Лекция 10. Универсализация
Слияние двух концепций - модуля и типа - позволило разработать мощное понятие класса, послужившее основой ОО-метода. Уже в таком виде оно позволяет делать многое. Однако для достижения наших целей - расширяемости, возможности повторного использования, надежности необходимо сделать конструкцию класса более гибкой. Развитие может идти в двух направлениях. Один, представленный вертикалью на следующем рисунке, показывает абстракцию и специализацию; он ведет к изучению наследования в последующих лекциях. В данной лекции изучается другая размерность (горизонталь на рисунке), параметризация (тип как параметр), известная также как универсализация.
Горизонтальное и вертикальное обобщение типа
Рис. 10.1. Размерности обобщения
Уже изученные механизмы позволяют написать класс, помещенный в центр рисунка - LIST_OF_BOOKS, экземпляр которого представляет список книг. У класса следующие компоненты: put для вставки элемента, remove для удаления элемента, count для подсчета числа элементов и т.д. Очевидны два пути обобщения понятия LIST_OF_BOOKS.
[x]. Списки являются специальным видом структур, представляющих контейнеры. Из многих других примеров контейнеров отметим деревья, стеки и массивы. В сравнение со списком LIST_OF_BOOKS, более абстрактным вариантом контейнера является класс SET_OF_BOOKS (множество книг). Более специализированным вариантом является класс LINKED_LIST_OF_BOOKS, определяющий связный список книг - специализированный вариант списка. Три класса задают вертикальную размерность на рисунке - размерность наследования.
[x]. Списки книг являются, с другой стороны, специальным случаем списков объектов некоторого вида. Из многих других видов отметим списки журналов, списки людей, списки целых чисел. Это горизонтальная размерность на нашем рисунке - размерность универсализации, тема нашего изучения в последующей части этой лекции. Если задать параметр класса, представляющий произвольный тип, то можно не создавать почти идентичные классы, такие как LIST_OF_BOOKS и LIST_OF_PEOPLE, не жертвуя при этом безопасностью, вносимой статической типизацией.
Отношение между двумя этими механизмами - трудный вопрос для изучающих ОО-концепции. Как рассматривать наследование и параметризацию, как соперников или как соратников, когда целью является построение более гибкого ПО?10.1)
Данная лекция посвящена универсализации, кроме того, мы подробно рассмотрим один из наиболее общих примеров родовых структур: массивы. Заметьте, термины универсальный класс, родовой класс, параметризованный класс являются синонимами. Во всех случаях речь идет о классе с параметрами, задающими некоторый тип (класс).
Необходимость параметризованных классов
Универсализация уже рассматривалась в данной книге, но не применялась для классов. Мы столкнулись с ней при обзоре традиционных подходов к повторному использованию и при изучении математической модели класса - АТД, где была показана необходимость определения параметризированного АТД.
Родовые АТД
Наш работающий пример АТД, STACK, был объявлен с параметром, как STACK [G]. Любое его использование заставляет специфицировать "фактический родовой параметр", представляющий тип хранимого в стеке объекта. Имя G, используемое в спецификации АТД, - формальный родовой параметр класса. Оно указывает, что элементы стека могут иметь любой возможный тип. При таком подходе можно использовать одну спецификацию для всех возможных стеков. Альтернативой, вряд ли приемлемой, было бы введение множества классов: INTEGER_STACK, REAL_STACK и т.д.
Любые АТД, описывающие контейнеры: множества, списки, матрицы, массивы и многие другие, очевидно, также должны быть родовыми.
Это решение применимо к контейнерам классам, также как к контейнерам АТД.
Проблема
Рассмотрим пример стека, но уже не как АТД, а как класс. Мы знаем, как написать класс INTEGER_STACK, задающий стек объектов типа INTEGER. Компоненты будут включать count (число элементов), put (вталкивание элемента), item (элемент в вершине), remove (выталкивание элемента), empty (пустой ли стек?).
Тип INTEGER будет часто использоваться в объявлениях этого класса. Например, это тип аргумента для put и результата для item:
put (element: INTEGER) is
Как рассматривать наследование и параметризацию, как соперников или как соратников, когда целью является построение более гибкого ПО?Как рассматривать наследование и параметризацию, как соперников или как соратников, когда целью является построение более гибкого ПО? 10.1