Читайте также:
|
В многопоточной версии проигрывателя один поток предназначался бы для считывания информации, второй – для обработки, а третий – для записи данных в видеобуфер, причем все они выполнялись бы параллельно, а обработка продолжалась бы даже во время чтения с диска – прирост производительности налицо! Можно привести еще много примеров, когда одновременное выполнение нескольких действий приводит к повышению производительности системы. Именно для увеличения производительности и реализована многопоточность в виртуальной машине Java* (JVM).
В данной статье освещаются следующие вопросы: реализация многопоточности в коде Java, оптимальная разработка параллельных программ, а также использование средств и ресурсов для разработчиков. Так как подробное рассмотрение всех вопросов не умещалось в рамках одной статьи, автор затронул в ней лишь ключевые детали. Подробную информацию об интересующих вопросах вы сможете получить из дополнительных ресурсов.
При запуске любой программы образуется, по крайней мере, один поток. В С/С++ и Java этот поток запускается при вызове метода main(). Для создания дополнительных потоков необходимо их запустить и назначить им определенные функции, после выполнения которых потоки автоматически будут завершены виртуальной машиной.
В среде Java для создания потока и назначения им функций есть два способа. Первым из них является наследование от класса Thread (входящего в пакет java.lang) с последующим переопределением метода run() на функцию, которую вы хотите назначить для потока.
Второй способ создания потока – использование класса с реализацией интерфейса Runnable (также из пакета java.lang). Этот интерфейс определит метод run(), который будет выполнять основную функцию потока, аналогично описанному выше первому способу.
Использование синхронизации – не единственный метод организации взаимодействия потоков. В среде Java версии J2SE* 5.0 доступно еще несколько удобных способов блокировки. Большинство из них находятся в пакете java.util.concurrent.locks, который стоит внимательно изучить для уверенной работы с потоками в среде Java.
37. Обзор операционной системы OS/2 и ее архитектуры
OS/2 создавалась как ОС для новой серии машин IBM Personal System/2, основанных на процессоре 80286. Архитектура системы представляет собой самое полное из известных автору воплощений идей, которые имел в виду Intel, разрабатывая этот процессор. Весьма ограничейный успех этой системы обусловлен, по-видимому, несостоятельно стью идей Intel, а не качеством их воплощения.
Система использует сегментированную виртуальную память и сборку в момент загрузки. Формат загрузочных модулей и DLL тот же самый, что в Winl6 NE. Однако система имеет раздельные адресные пространства задачи не имеют доступа к сегментам данных и приватным сегментам DLL других задач.
OS/2 реализует вытесняющую многозадачность, многопоточность в пределах одной задачи и богатый набор примитивов взаимоисключения. Ядро кооперативно многозадачное с управляемыми сообщениями асинхронными драйверами.
Одной из главных задач при разработке системы было максимальное облегчение переноса программного обеспечения из MS DOS. Эта цель была в основном достигнута: все системные вызовы DOS имели полные функциональные эквиваленты в OS/2, и достаточно аккуратно написанные программы для DOS могли быть перенесены в OS/2 1.x простой перекомпиляцией.
Переделка драйверов требовала отказа от совместимости с существующими драйверами устройств, файловых систем и сетевых протоколов для OS/2 1.x.
IBM предложила более элегантное решение, требовавшее, однако, переделки компилятора: предлагалось научить компилятор при вызове из 32-разрядного кода 16-битной процедуры генерировать специальный код, осуществляющий преобразование "плоского" указателя в сегментированный для всех параметров-указателей (пример П.1). Компилятор должен был принимать решение о необходимости такого преобразования на основе прототипа вызываемой функции.
Важно отметить, впрочем, что никаких реальных проблем реализация данного требования не представляла: практически все 32-разрядные компиляторы для OS/2 2.x Zortech C++, Watcom C++, IBM C/Set с успехом выполняют преобразование указателей.
Планирование и диспетчеризация процессоров в системе Solaris
Диспетчеризация процессора – предоставление всем процессам в системе по очереди в определенном порядке квантов процессорного времени. Главной целью диспетчеризации является максимальная загрузка процессора.
Работа любого процесса в системе представляется как последовательность чередований фаз активности процессора и активности ввода-вывода. Частота периодов активности процессора обратно пропорциональна их длительности.
Планировщик – компонента ОС, планирующая выделение квантов времени процессам по определенной стратегии. Различаются стратегии с прерыванием процессов и без прерывания процессов.
Диспетчер – компонента ОС, выполняющая само переключение процессора с одного процесса на другой. Время, которое на это требуется, называется скрытой активностью диспетчера и должно быть минимизировано.
Основные критерии диспетчеризации – использование процессора, пропускная способность системы, среднее время обработки одного процесса, среднее время ожидания одним процессом, среднее время ответа системы.
Для иллюстрации стратегий диспетчеризации используются диаграммы Ганта с изображением временной линейки, имен и периодов активности каждого процесса.
Стратегия диспетчеризации First-Come-First-Served (FCFS) – предоставление ресурсов процессора процессам в порядке их ввода в систему, независимо от их длительности.
Стратегия Shortest- Job -First (SJF) – предоставление ресурсов процессора более короткому процессу или сопроцессу, оставшееся время выполнения которого минимально.
Диспетчеризация по приоритетам предоставляет первым ресурсы процессора более высокоприоритетному процессу. Чтобы избежать ситуации "голодания", ОС постепенно повышает приоритеты процессов, длительное время находящихся в системе.
Стратегия Round Robin (RR) предоставляет всем процессам по очереди одинаковые кванты времени процессора. Квант времени не должен быть слишком мал, иначе накладные расходы на переключение процессов оказываются сравнимыми с полезным временем процессора.
Число переключений контекста с процесса на процесс возрастает с уменьшением выделяемого кванта времени.
Для обработки процессов различных классов и приоритетов ОС создает многоуровневые аналитические очереди процессов, каждая из которых обслуживается по различным стратегиям и (или) предоставляет процессам кванты времени различного размера.
При планировании загрузки многопроцессорных систем учитывается их симметричность или асимметричность. В асимметричных системах не требуется синхронизировать процессы по системным структурам данных, так как они доступны процессу только на одном процессоре.
В ОС Solaris и Windows 2000 выделяются процессы нескольких классов, для которых, соответственно, выделяются различные приоритеты. В системе Solaris для каждого класса процессов имеется свой планировщик.
73. Обзор многопоточности в Windows 2000 / XP / 2003 / 2008 / 7.
Модель один / один (one-to-one) – взаимно-однозначное отображение каждого пользовательского потока в определенный поток ядра. Примеры ОС, использующих данную модель, - Windows 95/98/NT/2000/XP/2003/2008/7; OS/2. Данная модель изображена на рис. 10.3.
Как уже отмечалось, в системе Windows реализована модель многопоточности "один / один". Каждый поток содержит:
· идентификатор потока (thread id);
· набор регистров
· отдельные стеки для пользовательских и системных процедур;
· область памяти для локальных данных потока (thread-local storage – TLS).
В многопоточной среде часто возникают проблемы, связанные с использованием параллельно исполняемыми потоками одних и тех же данных или устройств. Для решения подобных проблем используются такие методы взаимодействия потоков, как взаимоисключения (мьютексы), семафоры, критические секции и события
· Взаимоисключения (mutex, мьютекс) — это объект синхронизации, который устанавливается в особое сигнальное состояние, когда не занят каким-либо потоком. Только один поток владеет этим объектом в любой момент времени, отсюда и название таких объектов — одновременный доступ к общему ресурсу исключается. После всех необходимых действий мьютекс освобождается, предоставляя другим потокам доступ к общему ресурсу. Объект может поддерживать рекурсивный захват второй раз тем же потоком, увеличивая счетчик, не блокируя поток, и требуя потом многократного освобождения. Таков, например, mutex в Win32 и KMUTEX в ядре Windows. Тем не менее есть и такие реализации, которые не поддерживают такое и приводят к взаимной блокировке потока при попытке рекурсивного захвата. Это FAST_MUTEX в ядре Windows и критическая секция в Win32.
Дата добавления: 2015-04-20; просмотров: 23 | Поможем написать вашу работу | Нарушение авторских прав |