задержки. Заблокированный поток может быть переведен в состояние «готов к выполнению», и, следовательно, он становится готовым быть спланированным к выполнению или быть в состоянии «приостановлен».

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

23.3.2. Приоритеты потоков и алгоритмы планирования

В первом примере мы увидели, что каждый поток имеет приоритет. Но какие практические эффекты имеют приоритеты при выполнении потоков? Приоритеты влияют на алгоритм планирования, позволяя изменить порядок выполнения в случае, если поток с более высоким приоритетом переходит в состояние «готов к выполнению». Приоритеты являются фундаментальным аспектом ОСРВ и предоставляют фундаментные блоки для достижения коротких откликов на крайние сроки (deadlines). Важно подчеркнуть, что приоритет потока не связан с приоритетом IRQ.

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

После срабатывания IRQ задача, выполняющаяся в этот момент, формально в состоянии «выполняется», но она неэффективно выполняется в ЦПУ, который обслуживает ISR. Вызывая надлежащие процедуры ОС, которые мы увидим позже, ОС переводит наш аварийный поток в режим «готов к выполнению», но мы должны быть уверены, что это будет первый поток, который будет выполнен. Приоритеты позволяют программистам различать отложенные действия от не отложенных.

FreeRTOS имеет определяемую пользователем систему приоритетов, которая дает большую степень гибкости в определении приоритетов. Самый низкий приоритет (который означает, что потоки с этим приоритетом всегда будут пропускать потоки с более высоким приоритетом, если они готовы к выполнению) равен нулю. Затем пользователь может назначить увеличивающиеся приоритеты более важным потокам, вплоть до максимального значения, определенного символьной константой configMAX_PRIORITIES, которая определена в файле FreeRTOSConfig.h.

Таблица 1: Фиксированные приоритеты, определенные в спецификации CMSIS-RTOS

Вместо этого CMSIS-RTOS имеет четко определенную схему приоритетов, состоящую из восьми уровней (приведенных в таблице 1), которые сопоставлены с приоритетами

FreeRTOS. Функция

osStatus osThreadSetPriority(osThreadId thread_id, osPriority priority);

позволяет изменить приоритет существующего потока, в то время как функция

osPriority osThreadGetPriority(osThreadId thread_id);

позволяет получить приоритет существующего потока.

Говорить о приоритетах потоков совершенно бессмысленно, не зная точного алгоритма планирования (scheduling policy), принятого ОСРВ. FreeRTOS предоставляет три различных алгоритма планирования, которые выбираются правильной комбинацией символь-

ных констант configUSE_PREEMPTION и configUSE_TIME_SLICING, оба определены в файле

FreeRTOSConfig.h. В таблице 2 показана комбинация из этих двух макросов для выбора требуемого алгоритма планирования.

Таблица 2: Как выбрать требуемый алгоритм планирования во FreeRTOS

Давайте кратко познакомимся с этими алгоритмами.

•Приоритетное вытесняющее планирование с квантованием времени

(Prioritized preemptive scheduling with time slicing): это наиболее распростра-

ненный алгоритм, реализованный всеми ОСРВ, и он работает следующим образом. Каждый поток имеет фиксированный приоритет, который назначается при его создании. Планировщик никогда не изменит этот приоритет, но программист может переопределить другой приоритет, вызвав функцию osThreadSetPriority(). В этом режиме планировщик немедленно вытеснит выполняющийся по-

ток, если поток с более высоким приоритетом станет готовым к выполнению. Быть вытесненным означает быть недобровольно (без явной уступки (yielding) или блокировки) переведенным из состояния «выполняется» в состояние «готов к выполнению», чтобы позволить потоку с более высоким приоритетом стать выполняющимся. Квантование времени используется для распределения процессорного времени между потоками с одинаковым приоритетом, даже когда они оставляют управление, явно уступая или блокируясь. Когда поток «потребляет» свой временной интервал, планировщик выберет следующий готовый к выполнению поток в списке планирования (если имеется), назначив ему тот же временной интервал. Если доступных готовых к выполнению потоков нет, то планировщик помечает выполняющимся специальный поток с именем idle, который мы опишем далее. Временной интервал соответствует времени тика ОСРВ, которое по умолчанию равно 1 кГц, то есть 1 мс. Его можно изменить, сконфигурировав макрос configTICK_RATE_HZ и переставив частоту UEV таймера, используемого в качестве

генератора временного отсчета. Настройка этого значения зависит от конкретного приложения, а также от скорости работы микроконтроллера. Чем медленнее работает микроконтроллер, тем медленнее должно быть время такта. Обычно значение в диапазоне от 100 Гц до 1000 Гц подходит для многих приложений.

•Приоритетное вытесняющее планирование без квантования времени

(Prioritized preemptive scheduling without time slicing)22: этот алгоритм прак-

тически идентичен предыдущему, за исключением того факта, что, как только поток переходит в состояние «выполняется», он освобождает ЦПУ только на добровольной основе (блокируясь, останавливаясь или уступая) или если поток с более высоким приоритетом переходит в состояние «готов к выполнению». Этот алгоритм сводит к минимуму влияние переключения контекста на общую производительность, так как количество переключений значительно сокращается. Тем не менее, плохо спроектированный поток может установить полный контроль над ЦПУ, вызывая непредсказуемое поведение всего устройства.

•Кооперативное планирование (Cooperative scheduling): при использовании этого алгоритма поток освобождает ЦПУ только на добровольной основе (блокируясь, останавливаясь или уступая). Даже если поток с более высоким приоритетом становится готовым к выполнению, ОС никогда не будет вытеснять текущий поток, и она будет перепланировать его снова в случае внешнего прерывания. Эта форма планирования возлагает всю ответственность на программиста, который должен тщательно проектировать потоки, как если бы он разрабатывал микропрограмму без использования ОСРВ.

Даже если мы используем приоритетное вытесняющее планирование с квантованием времени следует уделять особое внимание при назначении приоритетов потокам. Давайте рассмотрим этот пример.

Имя файла: src/main-ex2.c

13int main(void) {

14HAL_Init();

15

16 Nucleo_BSP_Init();

17

18osThreadDef(blink, blinkThread, osPriorityNormal, 0, 100);

19osThreadCreate(osThread(blink), NULL);

20

21osThreadDef(uart, UARTThread, osPriorityAboveNormal, 0, 100);

22osThreadCreate(osThread(uart), NULL);

23

24 osKernelStart();

25

26/* Бесконечный цикл */

27while (1);

28}

29

30void blinkThread(void const *argument) {

31while(1) {

32HAL_GPIO_TogglePin(LD2_GPIO_Port, LD2_Pin);

22 Это алгоритм планирования по умолчанию, сконфигурированный CubeMX для микроконтроллеров

STM32F0/L0.

33osDelay(500);

34}

35osThreadTerminate(NULL);

36}

37

38void UARTThread(void const *argument) {

39while(1) {

40HAL_UART_Transmit(&huart2, "UARTThread\r\n", strlen("UARTThread\r\n"), HAL_MAX_DELAY);

41}

На этот раз у нас есть два потока, один из которых мигает светодиодом LD2, а другой постоянно выводит по UART2 сообщение. UARTThread() создается с приоритетом выше, чем у blinkThread(). Запустив этот пример, вы увидите, что светодиод LD2 никогда не мигает. Это происходит потому, что UARTThread() предназначен для непрерывного выполнения чего-либо, и когда его квант времени истекает, он все еще находится в состоянии «готов к выполнению» и, имея более высокий приоритет, он перепланируется на выполнение. Это ясно доказывает, что приоритеты должны использоваться осторожно, чтобы предотвратить нехватку ресурсов (starving) у других процессов23.

23.3.3. Добровольное освобождение от управления

Выполняющийся поток может освободить управление (говорят, что он уступает управление), если программист знает, что бесполезно использовать тактовые циклы ЦПУ, вызывав функцию

osStatus osThreadYield(void);

Она вызывает переключение контекста, и следующий готовый к выполнению поток в списке планирования переводится в состояние «выполняется». osThreadYield() играет действительно важную роль, если алгоритмом планировщика является кооперативное планирование.

23.3.4. Холостой поток idle

ЦПУ никогда не останавливается, если мы не перейдем в один из режимов пониженного энергопотребления, предлагаемых микроконтроллерами STM32. Это означает, что, если все потоки в системе заблокированы или остановлены в ожидании внешних событий, нам нужен способ «делать что-то», ожидая, когда другие потоки снова станут активными. По этой причине все операционные системы предоставляют специальные задачи с именем idle, которые планируются во время неактивных состояний системы, и ее приоритет определяется как минимально возможный. По этой причине принято говорить, что самый низкий приоритет соответствует приоритету холостой задачи idle.

До версии 9 во FreeRTOS всякий раз, когда поток удалялся, память, выделенная системой FreeRTOS потоку, освобождалась потоком idle. Во FreeRTOS версии 9, если один поток удаляет другой поток, то память, выделенная системой FreeRTOS удаленному потоку,

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

освобождается немедленно. Однако, если поток удаляет себя сам, то память, выделенная системой FreeRTOS потоку, все еще освобождается потоком idle. Обратите внимание, что во всех случаях автоматически освобождаются только стек и блок управления задачами (TCB), которые были выделены операционной системой потоку.

Поток idle также играет важную роль в проектах с пониженным энергопотреблением, как мы узнаем позже в этой главе.

Слово о конкурентном программировании

Вы будете поражены фантастическими числами, представленными вам разработчиками операционных систем реального времени. Они скажут вам, что их ОС способна обрабатывать сотни тысяч потоков в секунду, демонстрируя потрясающую производительность переключения контекста.

Знайте, что на практике это то же самое, что и в разговоры в пабах.

Рисунок 11: Что обычно происходит, когда число потоков увеличивается слишком сильно

Я часто просматриваю проекты, которые мне присылают читатели этой книги (но иногда я видел проекты с таким же плохим подходом, сделанные профессионалами, верите вы или нет), где вы можете увидеть десятки потоков, возникающих в коде, которые не делают ничего значимого. Иногда вы также можете найти потоки, которые не делают ничего, кроме разветвления другого потока после сравнения.

Теоретики конкурентного программирования научат вас, что чем больше у вас параллельных потоков, тем больше у вас проблем. Управление потоками может быть очень сложным, и зачастую затраты на их синхронизацию превосходят преимущества их использования. Более того, та же самая операция порождения нового потока имеет отнюдь не малые затраты. То же самое относится и к переключению контекста.

Многопоточное программирование всегда должно выполняться с осторожностью, особенно во встраиваемых системах, где SRAM часто действительно ограничена. Помните: будьте проще.