Содержание

4.6 Семафоры

Тесты в разделах 4.6.1, 4.6.2 и 4.6.3 обрабатывают создание и удаление семафоров. Пиковые значения результатов тестов связаны с прерываниями таймера, происходившими каждую миллисекунду во время измерений. Также рассматривается тот факт, что время удаления семафора не зависит от того, был он использован или нет. Т.е. предполагается, что при поступлении запроса на создание семафора все необходимые ресурсы уже выделены.

Тест синхронизации, результаты которого представлены в разделе 4.6.6, создает ситуацию, в которой несколько разноприоритетных нитей ожидают сигнала одного и того же семафора. В QNX NEUTRINO RTOS v6.2 существует 64 уровня приоритетов. Поскольку самый низкий уровень зарезервирован на задание «простоя» и не может быть использован приложениями, тест проводился с использованием 63 нитей.

Идея теста заключается в том, чтобы проверить, зависит ли сумма времени освобождения и времени переупорядочивания от числа ожидающих сигнала семафора нитей. Как показывают результаты теста, представленные на рисунке 4.6-12, для QNX NEUTRINO RTOS v6.2 такой зависимости нет. Измеряемые значения остаются постоянными для цикла тестов с числом ожидающих семафора нитей, варьирующимся от 1 до 63.

В QNX NEUTRINO RTOS v6.2 сумма времени освобождения и времени переупорядочивания является независимой от числа ожидающих одного и того же семафора нитей. Возможно, это означает, что система пересортировывает очередь ожидающих семафора нитей при каждом добавлении в нее новой нити. Результаты тестирования синхронизации были обработаны повторно для получения времени, которое требуется системе для того, чтобы захватить не сигнализирующий семафор и произвести переупорядочивание заданий, для запуска следующей нити (см. раздел 4.6.7). Всякий раз, когда нить пытается захватить не сигнализирующий семафор, она добавляется в очередь семафора. Цель этого испытания состоит в том, чтобы проверить, что время добавления новой нити в очередь семафора (и сортировки очереди!!) независимо от числа нитей в очереди.

Результаты представленные на рис. 4.6-14 (стр. 68) показывают, что никакой зависимости между временем сортировки очереди и числом нитей в ней нет.


4.6.1 Создание (SEO-a-1.d)

 

• Число нитей: 1
• Модель памяти: d

Рис. 4.6-1 SEO-a-1.d


Рис. 4.6-2 SEO-a-1.d - распределение частоты

• Число нитей: 1
• Модель памяти: d

Рис. 4.6-3 SEO-b-1.d


Рис. 4.6-4 SEO-b-1.d - распределение частоты

• Число нитей: 1
• Модель памяти: d

Рис. 4.6-5 SEO-c-1.d


Рис. 4.6-6 SEO-c-1.d - распределение частоты

• Число нитей: 1
• Модель памяти: d

Рис. 4.6-7 SEO-d-1.d


Рис. 4.6-8 SEO-d-1.d - распределение частоты

• Число нитей: 1
• Модель памяти: d

Рис. 4.6-9 SEO-e-1.d


Рис. 4.6-10 SEO-e-1.d - распределение частоты

• Число нитей: 63
• Модель памяти: d

Рис. 4.6-11 SEO-f-63.d


Рис. 4.6-12 SEO-f-63.d – Покомпонентное изображение

• Число нитей: 247
• Модель памяти: d

Рис. 4.6-13 Захват несигнализирующим семафором


Рис. 4.6-14 Захват несигнализирующим семафором – покомпонентное изображение

4.7 Мьютексы

Данный тест несвязанных между собой захватов и освобождений мьютекса, результаты которого представлены в разделах 4.7.1 и 4.7.2, реализован в виде непрекращающегося цикла захватов и мгновенно следующих за ними освобождений мьютекса.

В QNX NEUTRINO RTOS v6.2 реализован весьма критичный для RTOS механизм наследования приоритетов. Он протестирован путем создания 3 нитей, для которых сразу же возникла проблема инверсии приоритетов: нить с высоким уровнем приоритета претендовала на захват мьютекса, которым уже владела нить с более низким приоритетом, в свою очередь, нить со средним уровнем приоритета не давала запуститься нити с низким приоритетом и освободить мьютекс. Т.о., высокоприоритетная нить не могла захватить мьютекс.

В данном тесте оценено время, которое требуется высокоприоритетной нити для захвата мьютекса. В это время включалось время повышения приоритета низкоприоритетной нити, освобождение ею мьютекса и переключение на высокоприоритетную нить для предоставления ей возможности захватить мьютекс.

Рис. 4.7-5 (стр. 72) показывает, что механизм наследования приоритетов является стабильным: максимальное время для совершения этой серии операции не превышало 14мкс. И по-прежнему прерывания от таймера являлись причиной случайных выбросов.

Данный тест показывает значительные улучшения в системе, по сравнению с предшествующей версией. Очевидно, что проблема инверсии приоритетов является худшим случаем развития событий в системе реального времени. Сценарий развития событий в подобной ситуации был улучшен более чем на 30% по сравнению с предыдущей версией.

 

• Число нитей: 1
• Модель памяти: d

Рис. 4.7-1 SEO-d-1.d


Рис. 4.7-2 SEO-d-1.d - распределение частоты

• Число нитей: 1
• Модель памяти: d

Рис. 4.7-3 SEO-e-1.d


Рис. 4.7-4 SEO-e-1.d - распределение частоты

• Число нитей: 3
• Модель памяти: d

Рис. 4.7-5 SEO-g-3.d


Рис. 4.7-6 SEO-g-3.d - распределение частоты

• Число нитей: 1
• Модель памяти: d

Рис. 4.8-1 FS-a-1.d


Рис. 4.8-2 FS-a-1.d - распределение частоты

• Число нитей: 1
• Модель памяти: d

Рис. 4.8-3 FS-b-1.d


Рис. 4.8-4 FS-b-1.d - распределение частоты

• Число нитей: 1
• Модель памяти: d
• Число байтов: 1 байт

Рис. 4.8-5 FS-c-1.d.1


Рис. 4.8-6 FS-c-1.d.1 - распределение частоты

• Число нитей: 1
• Модель памяти: d
• Число байтов: 1 блок (512 байтов)

Рис. 4.8-7 FS-c-1.d.1b


Рис. 4.8-8 FS-c-1.d.1b – распределение частоты

• Число нитей: 1
• Модель памяти: d
• Число байтов: 10 блоков (5120 байтов)

Рис. 4.8-9 FS-c-1.d.10b


Рис. 4.8-10 FS-c-1.d.10b - распределение частоты

• Число нитей: 1
• Модель памяти: d
• Число байтов: 1 байт

Рис. 4.8-11 FS-d-1.d.1


Рис. 4.8-12 FS-d-1.d.1 - распределение частоты

• Число нитей: 1
• Модель памяти: d
• Число байтов: 1 блок (512 байтов)

Рис. 4.8-13 FS-d-1.d.1b


Рис. 4.8-14 FS-d-1.d.1b – Распределение частоты

• Число нитей: 1
• Модель памяти: d
• Число байтов: 10 блоков (5120 байтов)

Рис. 4.8-15 FS-d-1.d.10b


Рис. 4.8-16 FS-d-1.d.10b – распределение частоты

• Полный стек TCP/IP: полная реализация стека TCP/IP.
• Компактный стек TCP/IP: сильно сокращенная реализация TCP/IP стека для систем с ограниченными ресурсами.

Рис. 4.9-1: Полный TCP/IP стек – способность приема

Рис. 4.9-2: Компактный TCP/IP стек – способность приема

Рис. 4.9-3: Полный TCP/IP стек – способность отправки

Рис. 4.9-4: Компактный TCP/IP стек – способность отправки

• Целевая машина, у которой прерывание часов обладает самым высоким уровнем приоритета.
• Целевая машина, у которой прерывание часов имеет не самый высокий уровень приоритета.

Обычно Intel-компьютеры (по умолчанию) относятся к первой категории. Прерывание часов аппаратно установлено на IRQ0, который по умолчанию имеет уровень приоритета выше, чем уровень приоритета любого другого внешнего прерывания. Это означает, что каждое действие в системе (включая обслуживание важных внешних аппаратных прерываний) может быть прервано обслуживанием часов. Поэтому очень важно знать максимальное время работы ISR часов, так как это время ожидания необходимо добавить ко времени ожидания обработки прерывания для получения результатов в худшем случае. В результате, система медленнее реагирует на события. Таким образом, аппаратные архитектуры, у которых прерывания таймера имеет самый высокий уровень приоритета, не являются часто используемыми в системах реального времени.

Целевые машины с архитектурами аппаратного оборудования второй категории не обязательно присваивают прерыванию часов самый высокий уровень приоритета. Таким образом, система отреагирует на другие внешние прерывания (с уровнем приоритета выше, чем у прерывания часов) как можно быстрее, поскольку их обработка не будет задержана часами. Можно предположить, что выбор подобных архитектур наиболее соответствует системам реального времени, но есть один недостаток: низкий приоритет прерывания часов может вызвать неустойчивость в синхронизации часов. Для некоторых видов приложений, в которых важна точная частота тиков часов, это может быть неприемлемым.

В разделе были выполнены два теста на изучение времени выполнения ISR часов. Главная нить каждого теста остается неизменной: повторяющееся выполнение вычисления, занимающее около 224 мкс. Затем часы прерывают главную высокоприоритетную нить, и оценивается увеличение времени вычислений. Разница между нормальным (минимальным) временем вычисления и временем вычисления в худшем случае и есть худший случай времени обработки прерывания часов (никаких других прерываний в системе не возникает).

Первый тест, результаты которого представлены в разделе 4.10.1, включает только главную нить. И, как видно из рис. 4.10-1, непрерываемые вычисления занимают 224 мкс. Время вычислений во второй серии опытов колеблется около 228 мкс, что было вызвано возникновением прерывания часов. Можно сделать следующий вывод: стандартное время выполнения ISR часов составляет приблизительно 4 мкс (на Pentium 200 MHz).

Данный тест был повторен с добавлением дополнительных нитей, выполняющих оператор "sleep", который заканчивал свое действие в середине вычислений главной нити (это похоже на установку таймера). Результаты данного тестирования не приводятся, так как добавление дополнительных нитей никак не повлияло на время выполнения ISR часов.

Двумя главными операциями, выполняемыми ISR часов, являются обновление регистра счетчика часов и управление временем истечения таймера. С каждым тиком часов регистр счетчика должен обновляться и это минимальная работа, которую ISR часов должна выполнять снова и снова. Это случай, когда выполнение ISR часов занимает 4мкс.

С другой стороны, при выполнении ISR часов обновляется регистр счетчика и возможно истекает срок по таймеру, что может привести к выполнению дополнительной работы. В некоторых системах это приводит к значительному увеличению времени выполнения ISR часов. Как было отмечено ранее, эта проблема возникает для целевых машин, у которых прерывание по часам имеет самый высокий приоритет, так как это замедляет реакцию системы на другие прерывания.


4.10.1 Clock ISR – без загрузки системы и без таймеров

 

• Число нитей: 1
• Модель памяти: a

Рис. 4.10-1 ISR часов(без загрузки, без таймера)


Рис. 4.10-2 ISR часов (без загрузки, без таймеров) – Покомпонентное изображение

Рис. 4.11-1 Сравнительная характеристика времени переключения между нитями

Как видно из рисунка 4.11-1, минимальное, среднее и максимальное значения времени ожидания изменяются при загруженной объектами системе, но максимальное значение остается приемлемым - около 11мкс. Т.е. при загрузке системной памяти нитями не происходит значительной потери производительности.


4.12 Утечки памяти (Memory leaks)

Данный раздел определяет, приводят ли различные системные операции к утечкам памяти.


4.12.1 Создание/удаление семафоров и мьютексов

Цель данного раздела заключается в том, чтобы определить приводят ли системные операции создания и удаления семафоров и мьютексов к случаям утечки памяти. Тест реализован следующим образом (псевдокод):

LOOP 1000 times
 

Get Available Physical Memory
 

Create 100 Objects
 

Delete 100 Objects
END LOOP

Утечек памяти обнаружено не было.


4.12.2 Создание/удаление процессов

В данном разделе определяется, приводит ли создание и удаление процессов к утечкам памяти. Тест включает в себя родительский процесс, порождающий процесс – потомок.

В нижеследующих разделах рассматриваются четыре разновидности проведенных тестов:

1. Процесс–потомок не выполняет никаких действий, не размещается в памяти и не создает объекты и получает возможность корректно завершиться.
2. Процесс–потомок создает несколько семафоров, которые не удаляются и корректно завершает выполнение.
3. Процесс–потомок не выполняет никаких действий, не размещается в памяти и не создает объекты, но не получает возможности корректно завершиться. Вместо этого родительский процесс удаляет его во время выполнения.
4. Родительский процесс удаляет процесс–потомок во время его выполнения, но до того, как процесс–потомок создал семафоры.

4.12.2.1 Нормальное завершение процесса без создания объектов

Данный тест очень похож на аналогичный тест с нитями, но вместо нитей используются процессы. Был выполнен следующий тест (псевдокод):

LOOP 1000 times
 

CloseHandle(PROCESS) // Close the handle to the process
END LOOP

Главный цикл создает другой процесс и "засыпает" на 10мс для того, чтобы дать созданному процессу выполниться и завершиться. Создаваемый процесс содержит только одну нить, которая не производит никаких действий, только пишет один отсчет на анализатор PCI и может быть расценена как завершенная. В завершении, когда обработка процесса закончена, последовательность действий повторяется.

Утечек памяти обнаружено не было.


4.12.2.2 Нормальное завершение процесса с созданием объектов

Данный тест идентичен тесту раздела 4.12.2.1 (Нормальное завершение процесса без создания объектов), за исключением того, что создаваемый процесс создал в свою очередь 100 семафоров, не удаляемых после завершения процесса. При сравнении результатов с результатами предыдущего теста можно сделать вывод о том, что происходит с открытыми объектами при завершении процесса.

Утечек памяти обнаружено не было.


4.12.2.3 Принудительное удаление процесса без создания объектов

Данный тест идентичен тесту раздела 4.12.2.1 (Нормальное завершение процесса без создания объектов), за исключением того, что в данном случае создаваемый процесс не получает возможности корректно завершиться. Родительский процесс убивает процесс-потомок во время его выполнения.

Утечек памяти обнаружено не было.


4.12.2.4 Принудительное удаление процесса с созданием объектов

Данный тест похож на тест раздела 4.12.2.2 (Нормальное завершение процесса с созданием объектов), за исключением того, что в данном случае создаваемый процесс не получает возможности завершиться корректно. Родительский процесс убивает процесс- потомок во время его выполнения.

Утечек памяти обнаружено не было.

Далее >>>