Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Delphi Новый топик    Ответить
Топик располагается на нескольких страницах: 1 2      [все]
 Многопоточность - исследование длительности квантов времени  [new]
DmSer
Member

Откуда: Пенза
Сообщений: 1125
Многопоточность - исследование длительности квантов времени

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

Код метода TCalcQuantThread.Execute:
procedure TCalcQuantThread.Execute;
var
  StartTicks, BreakDiff, QuantDiff, CurQuantTime: Int64;
  PrevTicks, CurTicks, CurQuantStart: Int64;
  Freq: Int64;
begin
  QueryPerformanceFrequency(Freq);
  QueryPerformanceCounter(StartTicks);
  PrevTicks := StartTicks;
  CurQuantStart := StartTicks;
  BreakDiff := 5 * Freq;
  QuantDiff := Round(0.001 * Freq);
  CurQuantTime := 0;
  repeat
    QueryPerformanceCounter(CurTicks);
    Inc(LoopCount);
    if CurTicks - PrevTicks > QuantDiff then
    begin // Если разница оказалась больше 1 мс, значит ОС приостанавливала
          // работу потока и теперь начался отсчёт нового кванта
      AddToWorkList(CurQuantTime / Freq); // Сохраняем время работы потока
      AddToNotWorkList((CurTicks - PrevTicks) / Freq); // Сохраняем время простоя потока
      CurQuantStart := CurTicks;
      CurQuantTime := 0;
    end else
      CurQuantTime := CurTicks - CurQuantStart;
    PrevTicks := CurTicks;
  until (CurTicks - StartTicks) > BreakDiff;
  if CurQuantTime > 0 then // Обрабатываем длительность последнего кванта
    AddToWorkList(CurQuantTime / Freq);
  IsFinish := True;
end;


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


Вот такие выводы у меня получились:
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 выполнятся моментально, т.к. к этому времени все потоки уже завершат свою работу.
4 июн 20, 19:56    [22145900]     Ответить | Цитировать Сообщить модератору
 Re: Многопоточность - исследование длительности квантов времени  [new]
shalamyansky
Member

Откуда:
Сообщений: 157
Приятное исследование, спасибо.
DmSer

6) с помощью функции GetTickCount невозможно решить данную задачу (пытался с ней вначале), т.к. она начинает возвращать новое значение лишь спустя 16 мс. Такая у неё разрешающая способность.

См. SetSystemTimeAdjustment
Это разрешение можно задавать, начиная со 100 нс. Вроде бы. Так написано, можете попробовать.
4 июн 20, 21:44    [22145930]     Ответить | Цитировать Сообщить модератору
 Re: Многопоточность - исследование длительности квантов времени  [new]
wadman
Member

Откуда: Санкт-Петербург
Сообщений: 26658
DmSer
она начинает возвращать новое значение лишь спустя 16 мс.

Это если не ставить на десятке красивые анимационные темы и не запускать вижуал студии.
Майкросовтские (и не только) поделия играют этим показателем как им хочется.

Эксперимент показал, что сферический конь в вакууме ведет себя всегда одинаково.

ЗЫ. Я тоже этим игрался, когда мне нужна была быстрая реакция при общении с чувствительной железкой.
4 июн 20, 22:10    [22145945]     Ответить | Цитировать Сообщить модератору
 Re: Многопоточность - исследование длительности квантов времени  [new]
s62
Member

Откуда: Жуковский
Сообщений: 1129
DmSer,

на сайте MS пишут, что промежуток времени, который выделяется потоку (time slice) - примерно 20 мс.
https://docs.microsoft.com/en-us/windows/win32/procthread/multitasking

Сообщение было отредактировано: 4 июн 20, 22:14
4 июн 20, 22:15    [22145951]     Ответить | Цитировать Сообщить модератору
 Re: Многопоточность - исследование длительности квантов времени  [new]
misha mike
Member

Откуда:
Сообщений: 711
DmSer, все это можно было прочитать в книге Руссиновича и без экспериментов :)
4 июн 20, 22:19    [22145956]     Ответить | Цитировать Сообщить модератору
 Re: Многопоточность - исследование длительности квантов времени  [new]
Kazantsev Alexey
Member

Откуда:
Сообщений: 4469
shalamyansky
См. SetSystemTimeAdjustment
Это разрешение можно задавать, начиная со 100 нс. Вроде бы. Так написано, можете попробовать.

Эта функция совсем для других целей. Чтобы изменить точность GetTickCount нужно использовать функцию timeBeginPeriod.
4 июн 20, 22:19    [22145957]     Ответить | Цитировать Сообщить модератору
 Re: Многопоточность - исследование длительности квантов времени  [new]
DmSer
Member

Откуда: Пенза
Сообщений: 1125
s62
DmSer,

на сайте MS пишут, что промежуток времени, который выделяется потоку (time slice) - примерно 20 мс


Я тоже ожидал примерно такого значения. А по факту чаще 95 мс наблюдаю :)
4 июн 20, 22:24    [22145963]     Ответить | Цитировать Сообщить модератору
 Re: Многопоточность - исследование длительности квантов времени  [new]
Barmaley57
Member

Откуда: Москва
Сообщений: 5745
Гы))
4 июн 20, 22:26    [22145967]     Ответить | Цитировать Сообщить модератору
 Re: Многопоточность - исследование длительности квантов времени  [new]
misha mike
Member

Откуда:
Сообщений: 711
DmSer, в догонку. Безобидная на первый взгляд функция timeSetEvent (создание мультимедийного таймера) вторым параметром принимает точность таймера в миллисекундах. Так вот, это значение, как оказалось, становится длительностью кванта глобально для всей системы пока работает этот таймер.

P.S. Хех, опоздал...

Сообщение было отредактировано: 4 июн 20, 22:27
4 июн 20, 22:27    [22145968]     Ответить | Цитировать Сообщить модератору
 Re: Многопоточность - исследование длительности квантов времени  [new]
Kazantsev Alexey
Member

Откуда:
Сообщений: 4469
Barmaley57,

Кстати, ты там про QIP писал. Он мог не сам менять точность, а просто использовать компонент, который меняет, TVirtualTreeView, например ;)
4 июн 20, 22:35    [22145974]     Ответить | Цитировать Сообщить модератору
 Re: Многопоточность - исследование длительности квантов времени  [new]
defecator
Member

Откуда:
Сообщений: 39208
Kazantsev Alexey
Barmaley57,

Кстати, ты там про QIP писал. Он мог не сам менять точность, а просто использовать компонент, который меняет, TVirtualTreeView, например ;)


про QIP и я писал лет более 10-ти назад, что он размер кванта меняет.
4 июн 20, 23:01    [22145990]     Ответить | Цитировать Сообщить модератору
 Re: Многопоточность - исследование длительности квантов времени  [new]
Barmaley57
Member

Откуда: Москва
Сообщений: 5745
Я QIP случайно идентифицировал, как виновника, когда разбирался с "поехавшим" планированием потоков. Тогда меня этот прикол сильно удивил. Из-за одного приложения меняются механизмы планирования во всей системе! Мелкософты - они такие))
4 июн 20, 23:31    [22146004]     Ответить | Цитировать Сообщить модератору
 Re: Многопоточность - исследование длительности квантов времени  [new]
misha mike
Member

Откуда:
Сообщений: 711
Barmaley57
Из-за одного приложения меняются механизмы планирования во всей системе! Мелкософты - они такие))

А вы можете предложить иной способ надежного программного отсчета малых интервалов, кроме перенастройки шедулера?

Сообщение было отредактировано: 5 июн 20, 03:09
5 июн 20, 03:11    [22146046]     Ответить | Цитировать Сообщить модератору
 Re: Многопоточность - исследование длительности квантов времени  [new]
rgreat
Member

Откуда:
Сообщений: 6022
misha mike,

Чем вас QueryPerformanceCounter не устраивает?
5 июн 20, 03:16    [22146048]     Ответить | Цитировать Сообщить модератору
 Re: Многопоточность - исследование длительности квантов времени  [new]
misha mike
Member

Откуда:
Сообщений: 711
rgreat, всем устраивает, но измерять малый интервал -- это не то же самое, что выполнять некое действие с этим интервалом. Таймер дергает обработчик, а чтобы исполнять код каждую миллисекунду, нужно уметь переключать задачи как минимум с таким интервалом (а лучше чаще).
5 июн 20, 03:27    [22146050]     Ответить | Цитировать Сообщить модератору
 Re: Многопоточность - исследование длительности квантов времени  [new]
rgreat
Member

Откуда:
Сообщений: 6022
misha mike,

Запроектируйте алгоритм так что бы это было не важно. Как уже было сказано выше Windows это не система реального времени.

Тот кто всерьез рассчитывает на обратное - любовно раскладывает сам себе грабли.

Сообщение было отредактировано: 5 июн 20, 03:37
5 июн 20, 03:37    [22146052]     Ответить | Цитировать Сообщить модератору
 Re: Многопоточность - исследование длительности квантов времени  [new]
misha mike
Member

Откуда:
Сообщений: 711
rgreat
Запроектируйте алгоритм так что бы это было не важно.

Дело не в алгоритме, а в том, что в составе WinAPI есть таймер, который умеет срабатывать с периодом вплоть до миллисекунды. Реализовать такой таймер иным способом, кроме ускорения системного шедулера, -- невозможно. Microsoft не виноваты в том, что этот таймер работает именно так. Если они и виноваты в чем-то, то в том, что не написали об этом большими красными буквами в документации к безобидной на первый взгляд функции.
5 июн 20, 03:49    [22146054]     Ответить | Цитировать Сообщить модератору
 Re: Многопоточность - исследование длительности квантов времени  [new]
rgreat
Member

Откуда:
Сообщений: 6022
misha mike,

var
  hTim: THandle;
  Delay: Int64;
begin
  hTim := CreateWaitableTimer(nil, false, nil);// создаем таймер
  Delay := -10000000;// Delay задается в сотнях наносекунд.
  SetWaitableTimer(hTim, Delay, 0, nil,nil,false); // задаем настройки
  WaitForSingleObjectEx(hTim, infinite, true);// ждем 
  ShowMessage('Прошла одна секунда');

Таймер можно сделать цикличным а вместо WaitForSingleObjectEx заюзать каллбэк.

Сообщение было отредактировано: 5 июн 20, 04:13
5 июн 20, 04:08    [22146059]     Ответить | Цитировать Сообщить модератору
 Re: Многопоточность - исследование длительности квантов времени  [new]
rgreat
Member

Откуда:
Сообщений: 6022
http://www.windowstimestamp.com/description
5 июн 20, 04:27    [22146062]     Ответить | Цитировать Сообщить модератору
 Re: Многопоточность - исследование длительности квантов времени  [new]
kealon(Ruslan)
Member

Откуда: Нижневартовск
Сообщений: 5963
misha mike
rgreat
Запроектируйте алгоритм так что бы это было не важно.

Дело не в алгоритме, а в том, что в составе WinAPI есть таймер, который умеет срабатывать с периодом вплоть до миллисекунды. Реализовать такой таймер иным способом, кроме ускорения системного шедулера, -- невозможно. Microsoft не виноваты в том, что этот таймер работает именно так. Если они и виноваты в чем-то, то в том, что не написали об этом большими красными буквами в документации к безобидной на первый взгляд функции.
вы бы разобрались для начала в вопросе каким образом планировщик задач получает управление - тынц
5 июн 20, 10:45    [22146217]     Ответить | Цитировать Сообщить модератору
 Re: Многопоточность - исследование длительности квантов времени  [new]
_Vasilisk_
Member

Откуда: Украина, Харьков
Сообщений: 11914
DmSer
в диспетчере задач выполнить привязку процесса к одному ядру
SetThreadAffinityMask
DmSer
привязка потока к ядру процессора не является постоянной.
Чтобы не перегревать одно ядро
DmSer
При этом часто оказываются загружены несколько ядер
Дефект большой дискретизации диспетчера задач
DmSer
ОС старается распределить загрузку по всем доступным ядрам
Смотри выше. Равномерный разогрев
DmSer
Предполагаю, что поток отработал свой квант (предположим 50 мс), затем ОС его усыпила, но поскольку нет других потоков, которым нужен процессор, ОС тут же его пробуждает.
Смотри алгоритм работы планировщика
5 июн 20, 12:24    [22146311]     Ответить | Цитировать Сообщить модератору
 Re: Многопоточность - исследование длительности квантов времени  [new]
Kazantsev Alexey
Member

Откуда:
Сообщений: 4469
_Vasilisk_
Чтобы не перегревать одно ядро

_Vasilisk_
Смотри выше. Равномерный разогрев

Нагрев проца это не забота ОС. Процы сейчас сами умеют даже частоты поднимать для отдельных ядер, если есть нагрузка и не превышается TDP.
5 июн 20, 12:47    [22146329]     Ответить | Цитировать Сообщить модератору
 Re: Многопоточность - исследование длительности квантов времени  [new]
misha mike
Member

Откуда:
Сообщений: 711
kealon(Ruslan), и каким образом прерывание от таймера противоречит сказанному мной? Что вы вообще сказать хотели?
5 июн 20, 16:52    [22146503]     Ответить | Цитировать Сообщить модератору
 Re: Многопоточность - исследование длительности квантов времени  [new]
kealon(Ruslan)
Member

Откуда: Нижневартовск
Сообщений: 5963
misha mike,

пардонс, промахнулся - это на это 22146059 сообщение был ответ
5 июн 20, 16:57    [22146507]     Ответить | Цитировать Сообщить модератору
 Re: Многопоточность - исследование длительности квантов времени  [new]
misha mike
Member

Откуда:
Сообщений: 711
great, блокирующие функции типа WaitForSingleObject все равно завязаны на разрешающую способность шедулера. Они отпускают поток не мгновенно после изменения состояния ожидаемого объекта, а в лучшем случае тогда, когда отработает текущий поток, висящий на том же ядре. Да и то не факт, на ядро могут быть завязаны и другие потоки, которые тоже дождались разблокировки и квант получит один из них.

Сами сказали, что Windows -- не система реального времени, а значит не просто мгновенного, а вообще детерменированного по времени переключения контекста быть не может. В оптимистическом среднем случае это половина интервала работы шедулера. А в пессимистическом -- вообще многие секунды.

Что касается частой генерации события в цикле, то это детский сад. Мало того, что работа цикла будет прерываться другими потоками на неопределенное время, так еще и динамическое изменение частоты процессора сделает такой "таймер" неюзабельным.
5 июн 20, 17:03    [22146511]     Ответить | Цитировать Сообщить модератору
 Re: Многопоточность - исследование длительности квантов времени  [new]
rgreat
Member

Откуда:
Сообщений: 6022
misha mike,

Это да, но в целом точности в пару мс добиться вполне можно. Большую часть времени.

Сообщение было отредактировано: 5 июн 20, 17:33
5 июн 20, 17:35    [22146525]     Ответить | Цитировать Сообщить модератору
 Re: Многопоточность - исследование длительности квантов времени  [new]
Barmaley57
Member

Откуда: Москва
Сообщений: 5745
misha mike
динамическое изменение частоты процессора сделает такой "таймер" неюзабельным..
Не:
barmaley57
Высокоточный таймер реализован в отдельной микросхеме, его частота одна и та же практически на всех новых машинах и составляет порядка 3 580 000 отсчетов в секунду. Частота не зависит от каких-либо факторов и задается при старте машины.
8 июн 20, 12:49    [22147404]     Ответить | Цитировать Сообщить модератору
 Re: Многопоточность - исследование длительности квантов времени  [new]
tunknown
Member

Откуда:
Сообщений: 759
DmSer
В программе необходимо указать количество запускаемых потоков, а в диспетчере задач выполнить привязку процесса к одному ядру.
Пытались ли вы изучить, как влияет на общее время исполнения наличие переброса потоков между ядрами и его отключение, т.е. привязка к одному ядру? Когда поток переносится на другое ядро, то это должно бы приводить к уменьшению эффективности кеша конкретного ядра.
9 июн 20, 11:36    [22147898]     Ответить | Цитировать Сообщить модератору
 Re: Многопоточность - исследование длительности квантов времени  [new]
DmSer
Member

Откуда: Пенза
Сообщений: 1125
tunknown,

Нет, не пытался. Предполагаю, что разница будет не существенной, скорее всего её не удастся определить.
9 июн 20, 13:40    [22148064]     Ответить | Цитировать Сообщить модератору
 Re: Многопоточность - исследование длительности квантов времени  [new]
tunknown
Member

Откуда:
Сообщений: 759
DmSer
Нет, не пытался.
Жалко. Мало у кого есть соответствующий (почти)серверный процессор.

DmSer
Предполагаю, что разница будет не существенной, скорее всего её не удастся определить.
Возможно, это больше зависит от алгоритма, чем от процессора. Однако, думаю, что в случае сравнения, например, 128L1+256L2 vs 192L1+1024L2 более мощный процессор понесёт большие потери от поведения шедулера, размывающего нагрузку.
9 июн 20, 14:59    [22148116]     Ответить | Цитировать Сообщить модератору
 Re: Многопоточность - исследование длительности квантов времени  [new]
DmSer
Member

Откуда: Пенза
Сообщений: 1125
tunknown
DmSer
Нет, не пытался.
Жалко. Мало у кого есть соответствующий (почти)серверный процессор.


Повеселили, спасибо! :)
9 июн 20, 17:01    [22148194]     Ответить | Цитировать Сообщить модератору
 Re: Многопоточность - исследование длительности квантов времени  [new]
DmSer
Member

Откуда: Пенза
Сообщений: 1125
У меня утилита Руссиновича ClockResпоказывает на обоих компах Current timer interval = 1.000 ms, хотя никаких асек на компе не стоит. Кто так выставляет - не знаю.
Предполагаю, что в данный момент такая же ситуация у большинства пользователей.
А если так, что в большинстве случаев функция Sleep работает с точностью 1 мс.
Кстати, на размер кванта текущее разрешение системного таймера походу не влияет.
21 июн 20, 11:04    [22154459]     Ответить | Цитировать Сообщить модератору
 Re: Многопоточность - исследование длительности квантов времени  [new]
Kazantsev Alexey
Member

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

Я посмотрел на Win7 и 10, на обеих, после загрузки, интервал равен: 15.625. После запуска Delphi XE2 интервал устанавливается в 0.977. А вот 10.4 интервал уже не меняет, он остаётся дефолтным.
21 июн 20, 12:35    [22154499]     Ответить | Цитировать Сообщить модератору
 Re: Многопоточность - исследование длительности квантов времени  [new]
white_nigger
Member

Откуда: Тула
Сообщений: 2326
Если правильно помню, MS VS в единицу устанавливает
21 июн 20, 12:37    [22154501]     Ответить | Цитировать Сообщить модератору
 Re: Многопоточность - исследование длительности квантов времени  [new]
wadman
Member

Откуда: Санкт-Петербург
Сообщений: 26658
DmSer
хотя никаких асек на компе не стоит.

white_nigger
Если правильно помню, MS VS в единицу устанавливает

Многие майкрософтские поделки меняют интервал. В т.ч. даже анимационные темы (считай - ОС).
Но не все даже эту тему читают. Про гугл молчу.
21 июн 20, 20:36    [22154714]     Ответить | Цитировать Сообщить модератору
 Re: Многопоточность - исследование длительности квантов времени  [new]
DmSer
Member

Откуда: Пенза
Сообщений: 1125
Несмотря на то, что разрешение системного таймера выставлено в 1 миллисекунду, это никак не помогает функции GetTickCount (либо GetTickCount64) работать точнее. При таком вот коде:
  tc := GetTickCount;
  sleep(20);
  tc := GetTickCount - tc;


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

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

Таким образом, функция GetTickCount является очень грубым средством для замеров интервалов времени.
29 июн 20, 22:02    [22159275]     Ответить | Цитировать Сообщить модератору
 Re: Многопоточность - исследование длительности квантов времени  [new]
bk0010
Member

Откуда:
Сообщений: 4959
DmSer
Несмотря на то, что разрешение системного таймера выставлено в 1 миллисекунду, это никак не помогает функции GetTickCount (либо GetTickCount64) работать точнее. При таком вот коде:
  tc := GetTickCount;
  sleep(20);
  tc := GetTickCount - tc;


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

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

Таким образом, функция GetTickCount является очень грубым средством для замеров интервалов времени.
Скорее проблема в sleep: даже если она реально спит ровно 20 мс, то, скорее всего, ОС уже отдала процессор другому потоку (процессу).
29 июн 20, 22:17    [22159282]     Ответить | Цитировать Сообщить модератору
 Re: Многопоточность - исследование длительности квантов времени  [new]
Kazantsev Alexey
Member

Откуда:
Сообщений: 4469
DmSer,

Ты лучше про слип почитай.
29 июн 20, 22:18    [22159283]     Ответить | Цитировать Сообщить модератору
 Re: Многопоточность - исследование длительности квантов времени  [new]
DmSer
Member

Откуда: Пенза
Сообщений: 1125
Kazantsev Alexey
DmSer,

Ты лучше про слип почитай.


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

Прихожу к выводу, что msdn врёт:
msdn
The 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"?
29 июн 20, 23:01    [22159303]     Ответить | Цитировать Сообщить модератору
 Re: Многопоточность - исследование длительности квантов времени  [new]
Kazantsev Alexey
Member

Откуда:
Сообщений: 4469
DmSer,

Посыпаю голову пеплом. Херню я про точность GetTickCount написал. Забыл, что у меня в качестве лоурез таймера, по дефолту, используется мультимедийный, который timeGetTime. timeBeginPeriod влияет именно на него, а у GetTickCount период не меняющийся, его можно получить через GetSystemTimeAdjustment /lpTimeIncrement/.
30 июн 20, 00:03    [22159327]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: 1 2      [все]
Все форумы / Delphi Ответить