Да все в жизни начинается с игр. Дальше развитие к спутникам, станкам, связи и т.д.

Еще несколько вопросов, если позволите. Раз уж Вы такой знаток данной темы.
Ведь, в предложенной выше задаче, нас интересует не "реальное время" в конечном итоге,
а "чистое время" выполнения некоторой последовательности команд. Которое, как предполагается,
теоретически может быть прервано разнообразными прерываниями, в том числе, системными.
Как это решается?

Переключение задач происходит в соответствии с system-slice. Как сказано выше, это время зависит от Win - платформы
Если мы укладываемся со своими измерениями в этот интервал, то "все хорошо, прекрасная маркиза".
Если нет - надо принимать меры по снижению задач на переключение.
Понятно, что на тестовой машине должны быть "прибиты" некоторые сервисы, не нужно в этот момент слушать музыку, смотреть фильмы, лазать браузерами, антивирь отключен и т.п.
Еще один пример показан в коде выше - переключить текущий контент на real-time и не забыть вернуть его обратно в текущий или normal.

Есть инструменты по наблюдению за сервисами, которые хорошо "кушают" процессорное время.
К примеру - LatencyMonitor называется.
Основная задача - проследить на затраты interrupt service routine (ISR) и Deferred Procedure Call (DPC) и, что не критично для работы - отключить.

P.S.
На самом деле, не все так плохо. Если явно не запущены затратные приложения, то измерения по rdts и QPC дают правдивые и релевантные значения без специальной настройки тестовой машины.

P.P.S.
У Майкрософт, есс-но, есть свои инструменты для тестирования ISR & DPC:



Сообщение отредактировал Gruffly - Apr 8 2017, 22:21

Погодите. Переключения между задачами - это одна проблема.
Но ведь есть еще низкоуровневые аппаратные прерывания, которые "съедают" определенное время.
И повлиять на них никак нельзя, поскольку они имеют наивысший приоритет.
Как это учитывается?

Это следующий уровень, Вы к нему готовы?
DPC можно "запретить" на определенное время, можно отлавливать длину очереди DPC и отсчитывать время исполнения "команд" в DPC.

А, Вы?
Меня, собственно, только именно этот уровень и интересует.
Я Вам задавал "наводящие вопросы", чтобы выйти на эту тему. Прикидываясь "чайником".

Как быть с конвейером команд и данных? Перестановкой команд при выполнении их процессором из конвейера?
Ненормированным временем выполнения отдельных команд процессора? Это еще не все вопросы...
Вы готовы на них ответить?
Или хотя бы обсудить?

Уровень углубления зависит от того, что нам нужно.
Влезание в потроха возможно для кого-то может быть самоцелью, для меня всегда это разумный компромисс между задачей и уровнем погружения.
Задача, с которой началось обсуждение - замеры времени выполнения программы, ее части и погрешностей таких измерений.
Только, что провел тест на стандартной Win7 (не отключал ресурсные сервисы типа анивиря и пр., не маскировал прерывания, не переводил в реал-тайм и тд)
Тестовое время работы приложения 60 сек.
Из них:
ISR max = 42 мкс, всего 0.036% (DirectX)
DPC max = 483 мкс, всего 0.11 % (Nvidia driver)
HPF (hard page faults) = 0.08% (AVP подгадил)
Итого: 0.23%

По процессорам время на прерывания:
CPU0 = 0.345 ms
CPU1 = 0.013 ms
CPU2 = 0.013 ms
CPU3 = 0.018 ms
Итого: 0.65%

Вывод:
Ничего особо не предпринимая в части снижения затрат на системные вызовы (административно или программно),
мы получили погрешность 0.65% замера времени исполнения (60 сек) нашей программы.
Много это или мало - каждый решает за себя.
Если много - сначала идут административные действия, затем программные.
Из программных - подсчет статистики по системным вызовам, повышения статуса, маскирование доступных для этого прерываний.
И, есс-но, неоднократный запуск тестируемого ПО для набора стат. значимых результатов.

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

Разрешите и мне глупый вопрос, уж больно интересна тема. Были упомянуты инструменты и ОСи для реал-тайм и эмбед. Какие времена циклов может обеспечить Windows Embedded? И вообще насколько это актуально применение Windows Embedded в задачах с жесткими требования ко времени, например в автоматизации (есть примеры применения?)? Может ли она конкурировать, например, с QNX по совокупности факторов (цена, легкость в освоении, время на разработку, надежность и пр.)? Как там с портированием на самодельные аппаратные платформы?

На Arduino?

Для детей это никак не работа. Потом с появлением заинтересованности, успехов и мотивации это может перерасти в любимую работу. Но не всегда.

А при чем здесь работа? Я вообще не понимаю, как можно ходить на работу, как на каторгу! Работа должна приносить удовольствие. Самым идеальным вариантом является работа==хобби.

Я это и имел ввиду, когда возражал - см. выше ваши заметки.

Смотря в какие приборы эмбедируют. У нас автоматы поверхностного монтажа работают под управлением Винды XP. У меня векторный анализатор Rohde&Schwarz работает под виндой 7. Все вполне себе риалтайм.

Вот поэтому мастдайка и работа — несовместимые вещи. Мне вот понадобилось чертеж сделать в 3D, пришлось запускать эмулятор, а в нем "компас-3D". И хоть мастдайка в данном случае свою непосредственную роль выполняет — роль пускалки игрушек, а не операционной системы, все равно как-то коробит...
А еще мне нравится в коде ковыряться. Мне вот говорят: "пиши на пхытоне", на что я отвечаю, что роднее С ничего себе представить не могу. И, в отличие от пхытона, С значительно меньше косяков может вызывать при переходе, скажем, на новую версию gcc. Хотя, некоторые проблемы и возникают: скажем, свежий gcc матюкается на код, который раньше считался корректным — и приходится добавлять -Wno-trampolines и подобные флаги, чтобы оставить -Wall -Wextra…