Здравствуйте, Аноним, Вы писали:
А>... скажем socket's select ...
Это всё реализовано через WaitForMultiplyObjects. Эти вызовы возвращают управление немедленно (при соотв. событии), там нет специальных, преднамеренных задержек. На длительность системных задержек ты повлиять не можешь. Если для твоей программы задержка системы критична — значит твоё решение не верно.

Здравствуйте, Аноним, Вы писали:

Когда поток ждёт объект ядра (event, нарпимер), он находится в состоянии Waiting. Когда объект переходит в сигнальное состояние, поток может быть переведён в состояние Running, Ready или Transition. В какое именно, зависит от текущего состояния системы, приоритета данного потока, а также приоритетов других активных потоков в системе. При этом только состояние Running означает немедленный доступ потока к процессору.

Величина задержки Sleep(1) определяется настройкой системного таймера. По умолчанию это примерно 10 или 15 миллисекунд (зависит, насколько я понимаю, от харда) и может быть измененена до минимум до 1-й миллисекунды.

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

Здравствуйте, Jolly Roger, Вы писали:

JR>Здравствуйте, Mr. None, Вы писали:

JR>Мои слова очень легко проверить с помощью примерно такого кода
JR>

JR>timeEndPeriod(1);
JR>Sleep(100);
JR>QueryPerformanceCounter(&t1);
JR>sleep(1);
JR>QueryPerformanceCounter(&t2);
JR>timeBeginPeriod(1);
JR>Sleep(100);
JR>QueryPerformanceCounter(&t3);
JR>sleep(1);
JR>QueryPerformanceCounter(&t4);
JR>timeEndPeriod(1);
JR>

JR>и сравнив (t2-t1) и (t4-t3).

JR>По поводу звёзд ничего сказать не могу — не в курсе, потому Вам придётся самому как-то найти способ проверки.

JR>Квант 12 мСек я лично не видел. Равный или кратный ~10 и ~15 видел, а 12 — нет

Судить о величине кванта по каким-то замерам в пользовательском режиме — это извините нонсенс, даже не хочу комментировать. Всё что вы видели так это то, что ваш замер колеблиться между 10 и 15 милисекунд, то есть 12 ровно посередине. Я сужу об этой величине по открытым источникам и большинство из тех, что я находил говорят о числах 12 для пользовательских системах и 16 для серверных. В любом случае это не принципиально, тем более что разница минимальна.

По поводу timeBeginPeriod здесь (на RSDN) уже не одно копьё сломали. Из публичной документации совершенно не ясно, почему она имеет такое влияние на функции типа Sleep. Если же судить по исследованиям, то из стека вызовов видно, что функция в конечном итоге вмешивается в работу планировщика и вполне вероятно, что НА НЕКОТОРЫХ РЕАЛИЗАЦИЯХ, НА КОТОРЫХ ЭТО БЫЛО ПРОВЕРЕНО, влияет на его работу. Не удивлюсь, если даже меняет величину кванта или меняет приоритеты. Поскольку это побочный эффект не документирован, использовать его чревато — он может оказаться не переносимым.

Ещё раз повторюсь: не надо учить людей неправильному.

Добрый день всем!
Описание ситуации: использую overlapped file handlers для работы с COM-портами. Все работает, но все функции ожидания (SleepEx, WaitForSingle/MultipleObjectsEx) возвращают управление либо сразу (если к моменту их вызова ожидаемое событие уже свершилось-данные есть в приемном буфере или буфер отправки пуст), либо как минимум через 15 ms, даже если событие наступило раньше (скажем, через 2ms после вызова функции ожидания).
Собственно вопрос — можно ли уменьшить время простоя функции ожидания, т.е. чтоб она возвращала управление СРАЗУ ЖЕ по наступлению события (для примера выше — через 2 ms)? Либо использовать какой-либо другой механизм, скажем socket's select, которому на вход передавать файловые указатели на COM-порт (select для сокетов не имеет таких задержек)?

Здравствуйте, Аноним, Вы писали:

select работать вернее всего не будет и в любом случае ничего не даст. Эффект связан с особенностями работы планировщика и наличием других использующих процессор потоков. Попробуйте увеличить приоритет потока, который вызывает WaitForXXX

Здравствуйте, Аноним, Вы писали:

А>Либо использовать какой-либо другой механизм, скажем socket's select, которому на вход передавать файловые указатели на COM-порт (select для сокетов не имеет таких задержек)?

Может опрашивать через GetOverlappedResult с bWait == FALSE и ожидать активно?

Здравствуйте, Jolly Roger, Вы писали:

JR>select работать вернее всего не будет и в любом случае ничего не даст. Эффект связан с особенностями работы планировщика и наличием других использующих процессор потоков. Попробуйте увеличить приоритет потока, который вызывает WaitForXXX

Для сокетов select как раз дает эффект — возвращает по событию сразу, без задержки (просто если бы была задержка, то сеть под Windows работала бы очень медленно — попробуйте поставить после select:
Sleep(1);/*все равно будет задержка 16 ms */
и для интенсивного обмена — скорость сразу заметно упадет).

Я спросил по поводу сокетов потому, что обратный механизм т.е. ReadFileEx(socketHandle, ...) работает, вот я и предположил а вдруг работает и наоборот?

Подъем приоритета потока эффекта не дает.

А>Может опрашивать через GetOverlappedResult с bWait == FALSE и ожидать активно?

Не подходит — если спрашивать непрерывно, в цикле, то процессор отдаст все свое свободное время этому потоку ("100% загрузка" — это некрасиво). Если же сразу после опроса поставить даже минимальную задержку, Sleep(1); — будем снова получать задержку в 15 ms.

Здравствуйте, Аноним, Вы писали:

А как Вы измеряете эту задержку?

Здравствуйте, Jolly Roger, Вы писали:

JR>А как Вы измеряете эту задержку?

При помощи GetTickCount() и __asm{...rdtsc...) это для x86 процессоров.

Здравствуйте, Jolly Roger, Вы писали:

JR>Величина задержки Sleep(1) определяется настройкой системного таймера. По умолчанию это примерно 10 или 15 миллисекунд (зависит, насколько я понимаю, от харда) и может быть измененена до минимум до 1-й миллисекунды.

Я согласен, НО sleep отмеряет в 99% случаев правильные интервалы — и в 1 и в 2 миллисекунды. Вот и есть желание воспользоваться его свойствами.

JR>Windows не гарантирует какое-то детерменированное время реакции на события, а потому для построения систем реального времени она малопригодна, а при таких как у Вас требованиях к разрешению это вообще бесперспективно.

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

Здравствуйте, Аноним, Вы писали:

А>При помощи GetTickCount() и __asm{...rdtsc...) это для x86 процессоров

GetTickCount просто возвращает текущее значение системного счётчика, значения которого обновляется раз в те самые 10 или 15 миллисекунд, и способов это изменить нет. По крайней мере мне они не известны. Использовать GetTickCount для замера коротких интервалов нельзя. rdtsc связано с процессором, на многопроцессорных системах это необходимо учитывать.

А>Я согласен, НО sleep отмеряет в 99% случаев правильные интервалы — и в 1 и в 2 миллисекунды. Вот и есть желание воспользоваться его свойствами.

О каких 99% Вы говорите? sleep в 100% случаев даёт дискретность 10 или 15 мСек. По крайней мере, на всех системах NT-линейки, на которых мне это случалось проверить, оно так. Чтобы получить более высокое разрешение, необхолимо явно переконфигурировать таймер.

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

А>Это так, но получается как-то обидно — на другом конце провода висит самый обычный 8-разрядный контроллер, который с этой задачей справляется в фоне, а на этом конце — ой. По моим текущим требованиям я "выдавил" из Windows нужные мне временные периоды, просто хотелось бы, по возможности, соптимизировать и иметь временной резерв.

Странная какая-то обида Если система не подходит для данной задачи, значит надо или менять систему, или задачу, или способ её решения. На что или на кого тут обижаться?

А>По моим текущим требованиям я "выдавил" из Windows нужные мне временные периоды, просто хотелось бы, по возможности, соптимизировать и иметь временной резерв.

Ну дак оптимизируйте Просто ориентироваться надо на имеющиеся средства. А для этот надо хотя-бы примерно представлять, что они из себя представляют. Я-бы рекомендовал книгу Руссиновича и Соломона о внутреннем устройстве Windows.

Здравствуйте, Аноним, Вы писали:

А>Добрый день всем!
...
А>Собственно вопрос — можно ли уменьшить время простоя функции ожидания, т.е. чтоб она возвращала управление СРАЗУ ЖЕ по наступлению события (для примера выше — через 2 ms)? Либо использовать какой-либо другой механизм, скажем socket's select, которому на вход передавать файловые указатели на COM-порт (select для сокетов не имеет таких задержек)?

Для начала подучить матчасть. Это не функции ожидания медленные — это специфика работы у них такая.

1) Для выполнения ожидания эти функции переводят поток в режим ядра — уже одна эта операция весьма не быстрая и занимает в среднем около 1000 тактов процессора. Итого 1000 тактов в ядро + 1000 тактов обратно итого 2000 тактов (в случае гигагерцового процессора это примерно 2 микро-секунды).

2) После перехода в режим ядра, если событие ещё не случилось, поток теряет остаток процессорного кванта и ИСКЛЮЧАЕТСЯ ИЗ КАРУСЕЛИ ПЛАНИРОВАНИЯ. Эстафетная палочка переходит другому потоку. И пока он не отработает свой квант, ваш поток не имеет никаких шансов начать исполняться, если только приоритет вашего потока не выше. Размер кванта процессорного времени зависит от типа ОС. Для серверных ОС он одинаков для всех потоков и равен 16 ms. Для клиентских ОС он равен 12 ms для background процессов и увеличен для foreground процессов.

3) Даже если ожидаемое событие произошло в тот момент, когда текущий процесс закончил отрабатывать свой квант, скорее всего вы не получите управления, ибо ваш процесс будет всего лишь возвращён в карусель планировщика и помещён В САМЫЙ КОНЕЦ ОЧЕРЕДИ. Это означает, что прежде чем передать управление вам, свои кванты отработают как минимум ВСЕ процессы с тем же приоритетом, что и ваш, а как максимум и все процессы с большим приоритетом. Причём последние будут работать пока не заснут, каждый выталкивая процессы с меньшими приоритетами на задний план.

4) Передача управления другому процессу приводит к перелючению контекстов, эта операция примерно такая же "быстрая" что и переход в режим ядра. То есть добавляйте ещё n-ое количество тактов (сколько точно не знаю).

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

Если вам так критичны задержки в 15ms (что сравнимо с временем кванта, если вы могли заметить), то могу вам предложить ждать с помощью цикла. К примеру критическая секция так и делает: сначала некоторое количство времени ждёт с помощью цикла, чтобы не уходить в ядро зазря, а потом почестному засыпает на мьютексе.

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

Здравствуйте, Jolly Roger, Вы писали:

JR>Здравствуйте, Аноним, Вы писали:

...

JR>Величина задержки Sleep(1) определяется настройкой системного таймера. По умолчанию это примерно 10 или 15 миллисекунд (зависит, насколько я понимаю, от харда) и может быть измененена до минимум до 1-й миллисекунды.
...

Извините, но вы говорите неправду. Не нужно людей учить неправильному. Функция Sleep делает следующее: отбирает у потока остаток, кванта времени, убирает его из карусели планирования на время указанное в качестве аргумента. Когда время истекает, поток возвращается в конец очереди карусели планирования. Задержка в 15 милисекунд не связана ни с настройкой системного таймера, ни с положением звёзд на небе. Она связана лишь с размером кванта процессорного времени, выделяемого каждому потоку. Эта величина зависит только от одной вещи: опции "Processor scheduling". Которая доступна тут: My Computer / System Propertues / Advanced / Performance / Advanced. И Доступно вам всего 2 положения: делать как на серверах (16 милисекундный квант для всех) и как на клиентских машинах (12 милисекундный квант для фоновых задач и увеличненный до 30 милисекунд для задач на переднем плане). От ОС немного зависит алгоритм работы планировщика: дробить или нет квант на подкванты, способ увеличивания кванта для задач на переднем плане — дискретный или непрерывный и так далее, но величина в среднем остаётся неизменной примерно с NT 3.5.

Здравствуйте, Mr. None, Вы писали:

JR>>Величина задержки Sleep(1) определяется настройкой системного таймера. По умолчанию это примерно 10 или 15 миллисекунд (зависит, насколько я понимаю, от харда) и может быть измененена до минимум до 1-й миллисекунды.
MN>...

MN>Извините, но вы говорите неправду. Не нужно людей учить неправильному. Функция Sleep делает следующее: отбирает у потока остаток, кванта времени, убирает его из карусели планирования на время указанное в качестве аргумента. Когда время истекает, поток возвращается в конец очереди карусели планирования. Задержка в 15 милисекунд не связана ни с настройкой системного таймера, ни с положением звёзд на небе. Она связана лишь с размером кванта процессорного времени, выделяемого каждому потоку. Эта величина зависит только от одной вещи: опции "Processor scheduling". Которая доступна тут: My Computer / System Propertues / Advanced / Performance / Advanced. И Доступно вам всего 2 положения: делать как на серверах (16 милисекундный квант для всех) и как на клиентских машинах (12 милисекундный квант для фоновых задач и увеличненный до 30 милисекунд для задач на переднем плане). От ОС немного зависит алгоритм работы планировщика: дробить или нет квант на подкванты, способ увеличивания кванта для задач на переднем плане — дискретный или непрерывный и так далее, но величина в среднем остаётся неизменной примерно с NT 3.5.

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

timeEndPeriod(1);
Sleep(100);
QueryPerformanceCounter(&t1);
sleep(1);
QueryPerformanceCounter(&t2);
timeBeginPeriod(1);
Sleep(100);
QueryPerformanceCounter(&t3);
sleep(1);
QueryPerformanceCounter(&t4);
timeEndPeriod(1);

и сравнив (t2-t1) и (t4-t3).

По поводу звёзд ничего сказать не могу — не в курсе, потому Вам придётся самому как-то найти способ проверки.

Квант 12 мСек я лично не видел. Равный или кратный ~10 и ~15 видел, а 12 — нет

Всё остальное подробно расписано у того-же Соломона-Руссиновича, а переписывать всю книгу сюда целиком я не счёл возможным, извините

Здравствуйте, Mr. None, Вы писали:

MN> Размер кванта процессорного времени зависит от типа ОС. Для серверных ОС он одинаков для всех потоков и равен 16 ms. Для клиентских ОС он равен 12 ms для background процессов и увеличен для foreground процессов.

Я имел случай установить один и тот-же дистрибутив W2k Pro на две системы с разным хардом. При этом на одной было ~10 мСек, а на другой — 15 с мелочью. На текущей машине у меня стоит та-же W2k и WinXP Pro, две вполне себе клиентские машины. На обеих ~15,6 мСек.

MN>3) Даже если ожидаемое событие произошло в тот момент, когда текущий процесс закончил отрабатывать свой квант, скорее всего вы не получите управления, ибо ваш процесс будет всего лишь возвращён в карусель планировщика и помещён В САМЫЙ КОНЕЦ ОЧЕРЕДИ. Это означает, что прежде чем передать управление вам, свои кванты отработают как минимум ВСЕ процессы с тем же приоритетом, что и ваш, а как максимум и все процессы с большим приоритетом. Причём последние будут работать пока не заснут, каждый выталкивая процессы с меньшими приоритетами на задний план.

Единица планирования — поток. Процессы вообще не учавствуют в распределении процессорного времени, разве что их класс учитывается в вычислении приоритета потока.

MN>Если вам так критичны задержки в 15ms (что сравнимо с временем кванта, если вы могли заметить), то могу вам предложить ждать с помощью цикла. К примеру критическая секция так и делает: сначала некоторое количство времени ждёт с помощью цикла, чтобы не уходить в ядро зазря, а потом почестному засыпает на мьютексе.

Так делает крит. секция, если она инициализирована с помощью InitializeCriticalSectionAndSpinCount и только если код выполняется на многопроцессорной машине. "Не нужно людей учить неправильному"(c)

Здравствуйте, Jolly Roger, Вы писали:

JR>две вполне себе клиентские машины*

* — системы.

MN>2) После перехода в режим ядра, если событие ещё не случилось, поток теряет остаток процессорного кванта и ИСКЛЮЧАЕТСЯ ИЗ КАРУСЕЛИ ПЛАНИРОВАНИЯ. Эстафетная палочка переходит другому потоку. И пока он не отработает свой квант, ваш поток не имеет никаких шансов начать исполняться, если только приоритет вашего потока не выше.
Вообщето не только. Если другой поток переходит в режим ожидания переключение на ready поток из очереди происходит сразу же. Если вы единственный ready поток на этот момент времени вы сразу начнете работать

Здравствуйте, ononim, Вы писали:

MN>>2) После перехода в режим ядра, если событие ещё не случилось, поток теряет остаток процессорного кванта и ИСКЛЮЧАЕТСЯ ИЗ КАРУСЕЛИ ПЛАНИРОВАНИЯ. Эстафетная палочка переходит другому потоку. И пока он не отработает свой квант, ваш поток не имеет никаких шансов начать исполняться, если только приоритет вашего потока не выше.

O>Вообщето не только. Если другой поток переходит в режим ожидания переключение на ready поток из очереди происходит сразу же. Если вы единственный ready поток на этот момент времени вы сразу начнете работать

Из курса математики 1-ого курса мы помним, что над пустым множеством допустимы те же операции, что и над не пустым, поэтому имеем:
1) очередь планировщика пуста;
2) в её конец добавляется новый поток, вернувшийся из состояния ожидания, список потоков перед ним пуст;
3) он дожидается заверщения квантов времени для пустого списка потоков (то есть ждёт 0 секунд) и начинает исполняться...

Так что ваше утверждение логично следует из всего сказанного и не противоречит ему. Что вы имели в виду, я не понял.

Если уж на то пошло, то вариантов, когда поток лишается своего кванта времени масса:
1) он вызовет функцию SwitchToThread;
2) он запустит любую блокирующего (например, ввода-вывода или блокирующего чтения сообщения из очереди потока)

но это к делу отношения не имеет, поэтому предлагаю закрыть эту часть дискуссии — человек спрашивал совсем о другом.

MN>Так что ваше утверждение логично следует из всего сказанного и не противоречит ему. Что вы имели в виду, я не понял.
Ну значит я не понял что вы имеете ввиду, помедитируйте над особенностями русского языка, над тем что поток может перейти в wait не "выработав" до конца отпущенный ему квант времени и слудеющей из этого многозначностью выражения "пока он не отработает свой квант"

Здравствуйте, Аноним, Вы писали:

timeBeginPeriod? как возможный эффект — нагрузка на цпу и временные траблы

Здравствуйте, Jolly Roger, Вы писали:

JR>Я имел случай установить один и тот-же дистрибутив W2k Pro на две системы с разным хардом. При этом на одной было ~10 мСек, а на другой — 15 с мелочью. На текущей машине у меня стоит та-же W2k и WinXP Pro, две вполне себе клиентские машины. На обеих ~15,6 мСек.

Я уже ответил: судить о размерах кванта по каким бы то ни было замерам — это нонсенс. Конкретные цифры не принципиальны — они крутятся вокруг названных мной величин. Принципиален их примерное значение и способ раздачи квантов: единый большой для сервеных ОС, малый для фоновых процессов в клиентской ОС и увеличенный для активных процессов в клиентской ОС.
Если вам будет так удобнее, то мыслите в терминах больше-меньше
~10 ms < квант для background процессов на клиентской ОС < кванта для серверных ОС < кванта для foreground процессов на клиентской ОС < ~20 ms

Я конечно не помню, давно это всё было и живой w2k не видел уже года 3, но если мне склероз не изменяет то W2k была серверной ОС, а не "вполне себе клиентской"...


MN>>3) Даже если ожидаемое событие произошло в тот момент, когда текущий процесс закончил отрабатывать свой квант, скорее всего вы не получите управления, ибо ваш процесс будет всего лишь возвращён в карусель планировщика и помещён В САМЫЙ КОНЕЦ ОЧЕРЕДИ. Это означает, что прежде чем передать управление вам, свои кванты отработают как минимум ВСЕ процессы с тем же приоритетом, что и ваш, а как максимум и все процессы с большим приоритетом. Причём последние будут работать пока не заснут, каждый выталкивая процессы с меньшими приоритетами на задний план.

JR>Единица планирования — поток. Процессы вообще не учавствуют в распределении процессорного времени, разве что их класс учитывается в вычислении приоритета потока.

Ок, спасибо — исправил. Но: придираться к опечаткам — это последнее дело.


MN>>Если вам так критичны задержки в 15ms (что сравнимо с временем кванта, если вы могли заметить), то могу вам предложить ждать с помощью цикла. К примеру критическая секция так и делает: сначала некоторое количство времени ждёт с помощью цикла, чтобы не уходить в ядро зазря, а потом почестному засыпает на мьютексе.

JR>Так делает крит. секция, если она инициализирована с помощью InitializeCriticalSectionAndSpinCount и только если код выполняется на многопроцессорной машине. "Не нужно людей учить неправильному"(c)

Молодец — 5 баллов. Только речь шла не об этом и я ни назвал ни конкретных методов, ни способов использования. Критическая секция может так делать при определённых условиях, как пример, иллюстрирующий предложение.

Здравствуйте, Mr. None, Вы писали:

MN>Ок, спасибо — исправил. Но: придираться к опечаткам — это последнее дело.

Опечатка, это когда вместо "п" набирают "р". Это понятно, они рядом на клавиатуре. Бывают и более сложные опечатки. Но мне, признаться, трудно представить, как можно при наборе слова "поток" так опечаться, чтобы получилось "процесс", да ещё и неоднократно

Однако Вы правы, это была придирка — ответ и намёк на Вашу придирку к упрощенности и, как следствие, неточности моего описания.

JR>>Так делает крит. секция, если она инициализирована с помощью InitializeCriticalSectionAndSpinCount и только если код выполняется на многопроцессорной машине. "Не нужно людей учить неправильному"(c)

MN>Молодец — 5 баллов.

Спасибо, я старался.

MN>Только речь шла не об этом и я ни назвал ни конкретных методов, ни способов использования. Критическая секция может так делать при определённых условиях, как пример, иллюстрирующий предложение.

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

MN>Судить о величине кванта по каким-то замерам в пользовательском режиме — это извините нонсенс, даже не хочу комментировать. Всё что вы видели так это то, что ваш замер колеблиться между 10 и 15 милисекунд, то есть 12 ровно посередине. Я сужу об этой величине по открытым источникам и большинство из тех, что я находил говорят о числах 12 для пользовательских системах и 16 для серверных. В любом случае это не принципиально, тем более что разница минимальна.

Вы код запустите. На моей текущей системе задержка "колблется" между 15.55 и 15.7 без timeBeginPeriod и "вокруг" 1.94-1.97 с timeBeginPeriod. Если для Вас это укладывается в понятие "разница минимальна", то мне добавить нечего. Разве что напомнить, что обсуждали мы юзермодное поведение юзермодной функции sleep, а вовсе не квант планировщика, и делать для этого замеры в ring0 было-бы как минимум странно.

MN>Ещё раз повторюсь: не надо учить людей неправильному.

Вы фактически обвинили меня во лжи:

Извините, но вы говорите неправду.

Не в ошибке, прошу заметить, а именно во лжи, основываясь при этом не на фактах, а на собственных сомнительных умозаключениях. И извиняться, как я понимаю, не намерены. В таком случае я просто вынужден ответить — поучите жену щи варить, а мне извольте не указывать, что и как делать, Ваше мнение на этот счёт мне совершенно неинтересно.

Здравствуйте, Jolly Roger, Вы писали:

JR>Здравствуйте, Mr. None, Вы писали:

JR>Вы фактически обвинили меня во лжи:
Я обвинил вас в том, что вы говорите не правду. Ложь — это более тяжкое проявление этого явление — это преднамеренное высказывание неправды. В этом я вас не обвинял.

JR>

JR>Извините, но вы говорите неправду.

JR> Не в ошибке, прошу заметить, а именно во лжи, основываясь при этом не на фактах, а на собственных сомнительных умозаключениях.

Мой сомнительные умозаключения в развёрнутом виде приведены в этом посте

Автор: Mr. None
Дата: 16.02.11

, вместе с моими сомнительными тестами, ибо тут продолжать дискуссию бесперспективно, человек спрашивал о другом.

Здравствуйте, Mr. None, Вы писали:

JR>>Вы фактически обвинили меня во лжи:
MN>Я обвинил вас в том, что вы говорите не правду. Ложь — это более тяжкое проявление этого явление — это преднамеренное высказывание неправды. В этом я вас не обвинял.

JR>>

JR>>Извините, но вы говорите неправду.

Нет уж, уважаемый, не выйдет. Вы утверждали что я сказал не "не правду", а "неправду". Если Вы действительно не понимаете разницы, то я могу рекомендовать обратиться к толковому словарю русского языка, чтобы убедиться, что "неправда" и "ложь" — синонимы. Это убережёт от лишних недоразумений в общении с окружающими. Но судя по тому, что в этом посте Вы написали раздельно, всё Вы прекрасно понимаете.

MN>Мой сомнительные умозаключения в развёрнутом виде приведены в этом посте

Автор: Mr. None
Дата: 16.02.11

, вместе с моими сомнительными тестами, ибо тут продолжать дискуссию бесперспективно, человек спрашивал о другом.

Должен заметить, что в первой части этого поста

Автор: Mr. None
Дата: 16.02.11

ничего нового для меня не содержится. Что касается второй части, то из неё я кажется понял, что явилось камнем преткновения . Я всё время говорил о разрешении таймера, Вы же, похоже, ставили знак равенства между разрешением таймера и слайсом потока. Хм, вообще-то в том примере теста, который я приводил, вызов Sleep(100) перед замерами был вставлен совершенно не случайно, именно его наличие позволяло замерить разрешение таймера без искажений, вносимых планировщиком. Мне казалось, что его назначение очевидно, но коль уж было не понятно, так надо было хотя-бы спросить

Почему оно так, тоже вроде как совершенно очевидно — просто не существует иного способа повысить разрешение пользовательских мультимедийных таймеров, кроме как заставив планировщик чаще проверять потоки на предмет изменения их состояния

Да, и ещё по поводу описания алгоритма планировщика — он всё-таки несколько сложнее. Я бы рекомендовал обратиться к книге Соломона и Руссиновича "Внутреннее устройство Windows", где это описано намного лучше.