Многопоточность - исследование длительности квантов времени

В развлекательных целях разработал программу для измерения длительности квантов времени. В программе необходимо указать количество запускаемых потоков, а в диспетчере задач выполнить привязку процесса к одному ядру. Затем нажать кнопку "Запустить потоки на 5 секунд".

Код метода TCalcQuantThread.Execute:



Ссылка на архив с программой (исходники + исполняемый файл):


Вот такие выводы у меня получились:
1) привязка потока к ядру процессора не является постоянной. Это хорошо видно, если запустить только один поток и не привязывать его к ядру в диспетчере задач. При этом часто оказываются загружены несколько ядер (суммарная загрузка не более 100%).
2) ОС старается распределить загрузку по всем доступным ядрам. Если запущены 4 вычислительных потока, то ОС распределит нагрузку по 4-м ядрам (у меня 4-ядерный процессор без гипертрединга).
3) если за одном ядре запущен только один такой поток (вычислительный), то определить длительность кванта времени не удаётся. Предполагаю, что поток отработал свой квант (предположим 50 мс), затем ОС его усыпила, но поскольку нет других потоков, которым нужен процессор, ОС тут же его пробуждает.
4) квант времени - не такая уж маленькая величина. Типичная длительность кванта времена на моём ноутбуке с Intel Core i3 (поколение не знаю) составляет 95мс. Подчеркну - именно для потоков, выполняющих тяжёлые вычислительные задачи (т.е. грузят процессор на 100% и сами по своей воле не засыпают).
5) если запускать потоки с максимальным приоритетом на одном ядре, то происходит их последовательное выполнение. Т.е. если мы создадим 10 потоков с максимальным приоритетом на одном ядре, то будем ждать их завершения 50 сек (примерно так, но тут я недостаточно исследовал :)
6) с помощью функции GetTickCount невозможно решить данную задачу (пытался с ней вначале), т.к. она начинает возвращать новое значение лишь спустя 16 мс. Такая у неё разрешающая способность. А у функции QueryPerformanceCounter точность гораздо выше: менее 1 микросекунды.


Разработанный пример может оказаться полезен начинающим программистам, изучающим тему многопоточности.
Особенности программы следующие:
1) За уничтожение объекта потока отвечает форма TForm1. Объект потока не уничтожается автоматически при завершении работы метода Execute. При завершении работы потока выставляется поле "IsFinish := True", которое анализируется в событии таймера "TForm1.Timer1Timer".
2) Программа может создать любое количество потоков, которое укажет пользователь (в разумных пределах). Каждому потоку назначается порядковый номер, который передаётся при создании объекта потока с помощью конструктора "TCalcQuantThread.Create"
3) Для хранения ссылок на созданные объекты потоков используется список FList: TList.
4) При срабатывании таймера осужествляется обход списка FList в обратном порядке и для всех потоков, у которых выставлено IsFinish=True, осуществляется вывод собранной информации в компонент Memo1: TMemo, после чего объект потока уничтожается (T.Free), а соответствующий ему элемент удаляется из списка FList.
5) В том случае, если пользователь решил закрыть программу раньше, чем окончатся 5 секунд, в событии TForm1.FormDestroy произойдёт обход списка FList и для каждого объекта потока последовательно будет вызван метод Free. Посколько все потоки выполняются 5 секунд и заканчиваются почти в одно время, то вызов метода Free займет время только для самого первого элемента списка FList. Остальные вызовы Free выполнятся моментально, т.к. к этому времени все потоки уже завершат свою работу.

Я тоже ожидал примерно такого значения. А по факту чаще 95 мс наблюдаю :)

tunknown,

Нет, не пытался. Предполагаю, что разница будет не существенной, скорее всего её не удастся определить.

Повеселили, спасибо! :)

У меня утилита Руссиновича ClockRes показывает на обоих компах Current timer interval = 1.000 ms, хотя никаких асек на компе не стоит. Кто так выставляет - не знаю.
Предполагаю, что в данный момент такая же ситуация у большинства пользователей.
А если так, что в большинстве случаев функция Sleep работает с точностью 1 мс.
Кстати, на размер кванта текущее разрешение системного таймера походу не влияет.

Несмотря на то, что разрешение системного таймера выставлено в 1 миллисекунду, это никак не помогает функции GetTickCount (либо GetTickCount64) работать точнее. При таком вот коде:



в tc будут значения то 15, то 16, то 31, то 32.

Если же проводить замеры с использованием функции Now, то точность получается гораздо выше.

Таким образом, функция GetTickCount является очень грубым средством для замеров интервалов времени.

Я делаю замеры с использованием QueryPerformanceCounter, которая позволяет замерять интервалы почти с микросекундной точностью. Я вижу, что Sleep(20) занимает около 20 мс (плюс минус копейки). Замеры с использованием функции Now также показывают 20 мс.
Так что у меня нет сомнений, что Sleep выполняется 20 мс.

Прихожу к выводу, что msdn врёт:
msdnThe resolution of the GetTickCount function is limited to the resolution of the system timer, which is typically in the range of 10 milliseconds to 16 milliseconds.

Может фразу "limited to the resolution" следует интерпретировать как "limited to the max resolution"?