ARM, RISC-V контроллеры

Причём тут ассемблер. Очередь -- это скорей binary heap уже отсортированный по приоритету. И нужное где-то в середине, поиск за O(N) (или ещё как-то по критерию адреса упорядочивать дополнительно -- затраты на каждый чих в два-три раза выше, памяти тоже). Потом перетасовывать собственно очередь ввиду изменения позиции элемента, где-то на 2*log(N). Потом обратно то же самое. А очередей (в нормальных ОС, где ожидание более одного события) может быть более одной и подвышать приоритет может потребоваться отнюдь не одного, а возможно, чуть ли не у всех процессов вообще. И самое глупое при том, что если A с высоким приоритетом ждёт B с низким (и так 100500 раз в секунду), то не факт вообще, что подвышение приоритета для B что-то даст. Может быть B зависит не от процессорного времени ни разу, а от возникновения каких-то других событий. Все эти игрища с приоритетами растут от unix-подобного планировщика, который неспешно 20 раз в секунду может задуматься на ещё пару миллисекунд и решить кому сколько дальше исполняться. Потому что там упор на большое количество слабо связанных задач на одном процессоре и основной разделяемый ресурс там -- процессорное время. Но в embedded программировании это не так. В embedded скорей будет такое же большое количество но уже сильно связанных между собой задач. И переключение контекста будет не 20, а именно что 100500 раз в секунду по факту возникновения каких-либо событий, а процессорное время скорей будет с избытком в большинстве случаев