30 июня 2021
Паттерны проектирования
Шаблоны параллельного программирования
Заключительное видео в цикле «Паттерны проектирования».
Проблемы параллельной обработки
Глобальные концепции параллельного программирования:
Спектр решаемых проблем:
Типовые трудности:
Глобальные концепции параллельного программирования:
- параллелизм данных (data parallel);
- параллелизм задач (message passing).
Спектр решаемых проблем:
- равномерная загрузка процессоров;
- скорость обмена информацией между процессорами.
Типовые трудности:
- неумение программистов думать параллельно;
- взаимные блокировки;
- гонки.
Схема параллельного решения задач
Хотим получить:
Ускорение, эффективность, масштабируемость
Ускорение, эффективность, масштабируемость
- Ускорение – отношение времени выполнения лучшего последовательного алгоритмам к времени выполнения параллельного алгоритма.
- Эффективность – показывает, во сколько раз больше время выполнения задания одним процессором, чем время выполнения того же задания многопроцессорной системой , умноженное на число процессоров.
- Масштабируемость – при росте числа процессоров алгоритм обеспечивает увеличение ускорения при сохранении постоянного уровня эффективности использования процессоров.
Забываем о существовании:
- Теоретических ограничений:
- потери производительности для организации параллелизма –
согласно гипотезе Минского (Minsky), ускорение, достигаемое при использовании параллельной системы, пропорционально двоичному логарифму от числа процессоров (т.е. при 1000 процессорах возможное ускорение оказывается равным 10); - cуществование последовательных вычислений (законом Амдаля) при наличии всего 10% последовательных команд в выполняемых вычислениях, эффект использования параллелизма не может превышать 10-кратного ускорения обработки данных.
- потери производительности для организации параллелизма –
- Аппаратных ограничениях.
- Программных ограничениях.
- Люди все же не умеют думать параллельно.
Получаем:
гонки, блокировки, утечки памяти…
гонки, блокировки, утечки памяти…
- Состояние гонки (race condition)— ошибка проектирования многопоточной системы, при которой работа системы зависит от порядка выполняются фрагментов кода.
- Взаимная блокировка (deadlock) — ситуация в многозадачной системе, при которой несколько потоков находятся в состоянии ожидания ресурсов, занятых друг другом.
- Утечка памяти (memory leak) — процесс неконтролируемого уменьшения объёма свободной оперативной памяти, связанный с ошибками в ПО.
- Глобальное потепление — все ядра процессора заняты бесполезной работой (обработка исключений во всех потоках, синхронизаций потоков, и т.п.).
Шаблоны параллельного программирования
- Примитивы синхронизации.
- Monitor
- Interlock
- Mutex
- semaphore
- Barrier
- ReaderWriterLock
- LazyInitializer
- Active object.
- Double checked locking.
- Sheduler.
- Thread pool.
Monitor
Плюсы:
Плюсы:
- Применяется для организации критической секции внутри приложения, в качестве признака блокировки использует заданные объект.
- Работает только для ссылочных типов.
- Невозможно создать объект класса Monitor.
- Существует инструкция компилятора lock для краткой записи.
- Монитор хранит для каждого синхронизированного объекта:
- ссылку на поток, который в данный момент владеет блокировкой;
- ссылку на очередь готовности, содержащую потоки, готовые получить блокировку;
- ссылку на очередь ожидания, содержащую потоки, ожидающие уведомления об изменении состояния объекта с блокировкой.
Monitor
Interlock
- Позволяет создавать простые операторы для атомарных операций с переменными.
- Поддерживаемые потоко-безопасные операции:
- инкремент;
- декремент;
- обмен и считывание значений.
| CompareExchange() | Безопасно проверяет два значения на эквивалентность. Если они эквивалентны, изменяет одно из значений на третье |
| Decrement() | Безопасно уменьшает значение на 1 |
| Exchange() | Безопасно меняет два значения местами |
| Increment() | Безопасно увеличивает значение на 1 |
Mutex
Синтаксис использования
- Обеспечивает межпроцессную блокировку ресурса для монопольного доступа.
- Если один поток захватил Mutex, то другой сможет получить доступ к ресурсу, только поле освобождения Mutex.
- Может быть освобожден только тем потоком, который его занял.
- Подразделяются на локальные и глобальные.
Синтаксис использования
Semaphore
Синтаксис использования
- Счетчик для числа потоков, которые могут одновременно взять семафор.
- Поддержка межпроцессной синхронизации, т.е. глобальные именованные объекты.
- Не поддерживается идентификации потоков, любой поток может освободить семафор, даже взятый другим потоком.
Синтаксис использования
Double checked locking (DCL)
Предназначен для уменьшения накладных расходов получения блокировки. Сначала проверяется условие блокировки без синхронизации. И только если условие выполняется, поток попытается получить блокировку. Таким образом, блокировка будет выполнена только если она действительно была необходима.
Синтаксис использования
Предназначен для уменьшения накладных расходов получения блокировки. Сначала проверяется условие блокировки без синхронизации. И только если условие выполняется, поток попытается получить блокировку. Таким образом, блокировка будет выполнена только если она действительно была необходима.
Синтаксис использования
Что такое архитектура ПО?
Архитектура – это базовая организация системы, воплощенная в ее компонентах, их отношениях между собой и с окружением, а также принципы, определяющие проектирование и развитие системы. [IEEE 1471]
Для чего нужна, на что влияет:
Архитектура – это базовая организация системы, воплощенная в ее компонентах, их отношениях между собой и с окружением, а также принципы, определяющие проектирование и развитие системы. [IEEE 1471]
Для чего нужна, на что влияет:
- определяет структуру;
- определяет поведение;
- концентрируется на значимых элементах;
- воплощает решения на основе логического обоснования.
Проблемы выбора
Плюсы:
Плюсы:
- Выбор часто обусловлен нефункциональными требованиями.
- Необходимо учитывать:
- эффективность разработки;
- удобство сопровождения;
- надежность целевой системы;
- технические компетенции разработчиков продукта;
- окружение эксплуатации продукта.
Архитектурные шаблоны
| Название | Сильные стороны | Сильные стороны |
|---|---|---|
| Layered | Декомпозиция решаемых задач по слоям. Позволяет стандартизованно наращивать функционал. Инкапсуляция изменений в рамках слоя. | Как и все – не является универсальной. Некоторые слои могут быть избыточными. |
| Client-Server | Общепринятый подход для обеспечения взаимодействия запрос-ответ. | Для обработки каждого запроса необходим отдельный поток исполнения на сервере. Обязательно межпроцессное взаимодействие. |
| Master-Slave | Исполнение сервисной функции делегируется различным специализированным исполнителям. | Slave является изолированным исполнителем. Высокие задержки взаимодействия. |
| Broker | Динамическое распределение бизнес функций. | Высокие требования к стандартизации протоколов информационного обмена. |
| Peer-to-Peer | Поддерживает распределенные вычисления. Высокая отказоустойчивость системы в целом. Высокая горизонтальная масштабируемость. | Не гарантирует работу единичного узла. Сложности с обеспечением безопасности. Трудно прогнозируемая производительность. |
| Event bus | Простота добавления/изменения сообщений информационного обмена. Высокая эффективность для распределенных систем. | «Бутылочным горлышком» является сама шина, т.к. является единственным звеном обеспечивающим транспорт сообщений. |
| Model View Controller | Поддержка нескольких представлений для одной и той же модели. Возможность подмены представлений в run-time. | Относительно высокая сложность. |
| MicroServices | Возможность частого обновления элементов. Выше общая доступность системы. Проще соблюдение принципов SOLID. | Повышенные требования к согласованности данных/интерфейсов. Повышенные требования к поддержке инфраструктуры. |
Layered (слоистая архитектура)
Типовой пример:
Типовой пример:
- Presentation layer (– UI layer).
- Application layer (– service layer).
- Business logic layer (– domain layer).
- Data access layer (– persistence layer).
Broker
Пример - RabbitMQ
Поток сообщений в RabbitMQ:
Поток сообщений в RabbitMQ:
- Поставщик публикует сообщение в обработчик.
- Обработчик получает сообщение и отвечает за его перенаправление. Обработчик учитывает различные атрибуты, такие как, ключ роутинга, зависимость на тип обмена и другие.
- Создается связь между обработчиком и очередью.
- Сообщение остается в очереди до тех пор пока не будет обработано получателем.
- Получатель обрабатывает сообщение.
Model-View-Controller
Основная идея этого паттерна в том, что и контроллер и представление зависят от модели, но модель никак не зависит от этих двух компонент.
Признаки контроллера:
Основная идея этого паттерна в том, что и контроллер и представление зависят от модели, но модель никак не зависит от этих двух компонент.
Признаки контроллера:
- Контроллер определяет, какие представление должно быть отображено в данный момент.
- События представления могут повлиять только на контроллер.
- Контроллер может повлиять на модель и определить другое представление.
- Возможно несколько представлений только для одного контроллера.
Вам также может быть интересно