Как лучше реализовать асинхронную задержку?

Question

[Dyikot]

Недавно ознакомился с сопрограммами 20 стандарта и тут возникает вопрос о правильности реализвации задержки. На данный момент я реализовал задержку в пределах одного потока. В основном цикле производится их обработка, т.е есть приоритетная очередь и просто проверятся вышло ли время и если да то используя обработчик сопрограммы производится ее "продолжение". И проблема какая. У меня в цикле стоит еще задержка равная частоте обновления монитора. И если 60 Гц, то эта проверка будет производится каждые ~16.667 мс. Что оказывается неточность при небольших задержках. И Вот тут возникает вопросы. А может лучше тогда перенести обработку на отдельный поток? Но ведь продолжение всеравно придется вызывать в основном потоке? Или может изменить обработку задержки?
Также у меня есть реализвация таймера, который ждет в отдельном потоке. Можно было бы его использывать, но тогда на каждую зарержку отдельный поток...

Comments

[Mercury13]

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

[Dyikot]

Mercury13, Это да. Сейчас по сути я это и делаю все в одном потоке. Я думаю перенести логику проверки прошло ли время в другой поток для точности. На основном (UI) потоке у меня опрос производится с задержкой допустим каждые 16мс. И например если я выполню следующее:

co_await AsyncTasks::Delay(1000); // Ожидаю 1000 мс получаю 1008 мс

И вот если перенести на другой поток то будет ок если продолжение будет выполнять на другом потоке или мне надо все равно ждать основной поток и на нем вызывать. Или может есть иной путь?

[Mercury13]

Если 8 мс так критичны — а вы, вероятно, пишете игру или плеер — то не стоит делать это методом задержек. В точке А (независимо, поток это или ещё что-нибудь) засеките время таймером мультимедийной точности, в точке Б проверяйте. Может быть такое, что сначала прикидываем, какую задержку надо сделать с UI-точностью без расхода процессора (например, 950 мс), а потом дотягиваем с мультимедийной точностью и расходом процессора.

Вы хорошо знаете, что есть несколько разных методик отсчёта задержек, и Sleep() — это, скажем, UI-точность.

[Mercury13]

Да и ЧТО тут делает co_await delay, если простой вызов delay() сделает не хуже?

[Mercury13]

Если смысл в том, что delay сам по себе занимается различным ремеслом — ну, не забывайте, что ремесло заканчивается когда заканчивается. У вас довольно жёсткое реальное время, и вообще надо серьёзно понимать, как это реальное время работает, чем занимается и сколько отнимает каждая из функций.

[Dyikot]

Mercury13, чтобы не блокировать поток?

[Mercury13]

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

[Dyikot]

Mercury13, 1 секунду я примерно написал, для того времени не критично, но например если 100мс, то да. Опять же задежка у меня привязана к частоте монитора. И тут уже погрешности не постоянна. И чтобы невелировать этот рандом тогда лучше будет проверять на другом потоке и возобновлять сопрограмму на нем же.
Сделал проверку как в c# реализовано и там разные тоже потоки. Думаю сделать аналогичным образом.

[res2001]

Dyikot, Какая ОСь?

На десктопных операционках квант времени, выдаваемый потоку (процессу) на работу до его вытеснения 1-10 мс. После истечения кванта поток вытесняется с выполнения ядром ОС. В линуксе, вроде бы, квант времени может быть плавающий, начинает с 10 мс и, если нужно, может уменьшаться вплоть до 1 мс.

Ваши 8 мс вполне укладываются в это ограничение. Если в данный момент времени в системе есть другие потоки, готовые работать, то такие задержки это нормально и я бы вообще не ожидал лучшего результата с применением таймеров (или sleepа того же) и загруженной системе.

Как-то поправить положение, можно, например выделив для этой задачи отдельный высокоприоритетный поток. В линуксе этому потоку так же можно задать Realt-Time планирование с повышенным приоритетом - в этом случае все типичные потоки с "общим" планированием будут менее приоритетны. В винде не знаю, есть ли подобные фишки, но приоритет то поднять точно можно. Еще как вариант привязать поток к одному ядру процессора - теоретически это может улучшить работу с кешем процессора. Обычно, так делают, при интенсивном обмене сетевым трафиком. В линуксе можно указать affinity для конкретного сетевого адаптера и если процесс в user space, который работает с этим адаптером, будет так же работать на этом же ядре, то будет неплохой буст в производительности. Поможет ли это вам, сказать трудно, надо проверять.

В целом идея Mercury13 с засечкой времени и проверкой в нужных местах мне нравится. Сам так иногда делаю в подходящих ситуациях. Но в этом случае ваш поток должен что-то делать во время активного ожидания. Если ему заняться не чем, то можно повисеть на condvarе с таймером. Читал, что в кондваре несколько другой механизм используется, чем в таймерах и тех же sleepах, правда это относилось к линуксу. И кондвар может быть более отзывчивым из-за этого. Так же видел проекты с применением этой идеи, где были реализованы собственные таймера с ожиданием на кондваре.

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

Миллисекундные задержки - это все таки мягкое реальное время, в жестком в микросекундах считают задержки и там уже совсем другие ОС. Что касается стандартных десктопных ОС (линукс и винда), то они ни разу не Real-Time и ожидать от них RT поведения не стоит. В Линуксе еще можно использовать ядро с RT_PREEMPT патчем, который делает линукс немного более Real-Time, но это уже не обычное ядро, этим надо специально заморачиваться.
RT ОСь отличается от не RT тем, что в RT четко определенные задержки для всех операций. В винде и линуксе, если ядро, например, начнет что-то подкачивать из файла подкачки, то задержки легко могут увеличиться в несколько раз. Файл подкачки в этом случае - это просто как пример того чем может быть занята ОСь, когда не дает работать вашей задаче.

[Dyikot]

res2001, Делаю на Windows. Планирую выпустить на всех desktop плафтормах. Для сихронных задержек < 10мс я использую SDL_DelayNS.

[Dyikot]

res2001, У меня отдельный класс Timer использует std::condition_variable_any и обеспечивает хорошую точность, по крайней мере по сравнению с std::this_thread::sleep_for.

[res2001]

Dyikot, Никаких особых чудодейственных средств в библиотеках нет, SDL_DelayNS использует что-то, предоставляемое системой.

На линуксе, мне доводилось укладываться по задержкам в 1 мс (+-несколько сот мкс), на высокоприоритетном потоке с RT планированием. Поток должен был просыпаться каждую 1 мс и делать свое черное дело. Ждал на кондваре, т.к. там по мимо пробуждения по таймауту могли быть и другие асинхронные события, которые будили поток.

[Dyikot]

res2001, Если задержка нужна постоянная то тогда да, но если нет то окно в 10мс есть.

[res2001]

Dyikot, Что да? При чем тут постоянная задержка?
Я просто описываю механизм с помощью которого мне удавалось делать в потоке достаточно точные не большие паузы.
У меня там не было фиксированной задержки. Задача была добиться пробуждение потока каждую 1мс с желательно равными промежутками времени, при этом еще учитывалось время работы самого потока (он же не моментально отрабатывает) и таймаут следующего пробуждения рассчитывался каждую итерацию с учетом затраченного на работу потока времени. Поэтому реальный таймаут, передаваемый в кондвар был меньше 1 мс.

Answer 1

[Mercury13]

Расспросы выяснили вот что.
Жёсткое реальное время, вероятно мультимедиа: 8 мс — грубо.
Следить за загрузкой едва ли способен. Поток загружен постоянно, задания довольно крупные.
В таком случае поможет многопоточка, главное — придумать, как перекидывать данные из потока в поток.

Answer 2

[rPman]

не нужно ждать интервалы времени, это абсурдно и неправильно!

на windows официальный способ через directx 11 (windows 8+)
https://learn.microsoft.com/en-us/windows/uwp/gami...
примеры гуглятся отвратительные включая msdn, но ИИ выдает их в сжатом и понятном виде:

IDXGISwapChain2* swapChain2; // должен быть получен через QueryInterface
swapChain2->SetMaximumFrameLatency(1);
HANDLE hWaitable = swapChain2->GetFrameLatencyWaitableObject();

// основной цикл
for (;;)
{
    // ждём, пока можно обновлять кадр
    WaitForSingleObjectEx(hWaitable, INFINITE, TRUE);

    RenderFrame();
    swapChain2->Present(1, 0);
}

p.s. еще есть фича монитора (и соответственно видеокарты) nvidia g-sync и amd freesync но это сугубо внутренняя ведь видеокарты, она меняет время обновления монитора в угоду приложения (т.е. не ты ждешь а тебя) но управлять этим напряму не получится... она включается по команде swapChain->Present(0...); (если 1 то использовать v-sync), лично сам никогда этим не пользовался, в жизни только один раз писал приложение синхронно vsync и это было давно и работало коряво (но это проблема была во времена winxp-win7 сейчас с этим лучше).

сам считаю что g-sync это отвратительная фича в той форме что преподносится... для приятных ощущений fps должен быть стабильным, и не обязательно бесконечно большим.. после 60Hz начинаются артефакты уже оборудования (дешевое оборудование и тут уже глючит), и только дорогие mid-end и выше мониторы (это от 50т.р. есть дешевле но там другие проблемы) позволяющие в некоторых случаях эту частоту поднять но артефакты будут, их просто не видно невооруженным глазом. Если же постоянно подруливать частотой обновлений, то эта нестабильность будет сразу заметна и создавать ощущение 'тормозов', вынуждая повышать fps что бы это убрать.

Очень небольшой класс игр требует частоты выше 60, а если честно, подавляющему большинству хватит 40 (кто то скажет 30 но там нужно править видеоряд, добавляя смазывание, что создает другие проблемы)... Посмотрите на эти тесты https://testufo.com/ (не всякое железо в браузере позволит выше 60Hz обновлять но если позволит, рекомендую посмотреть)

g-sync позволит изменить частоту разрешения монитора до требуемой без изменения видеорежима, но на практике в игре в лучшем случае будет выбор 30..60..10500Hz а не число по желанию.

Повторюсь, важна стабильность, любое отклонение от нее воспринимается как тормоза.

Comments

[Dyikot]

Ничего не понял что вы хотели сказать.
1) Мне windows only решения не нужны.
2) В SDL есть способ включить VSync. Но я делаю не игру и рендеринг у меня не каждый кадр а при изменениии соостояния объектов. И поэтому я не могу использовать VSync.
3) И интервалы я не жду а проверяю прошло ли время. И причем тут асинхронная задержка и зажержка кадра тоже не понял.

[rPman]

кроссплатформенно, это значит аналогичные методы у OpenGL и возможно уже Vulcan api. Обвязку. канвас и т.п. придется так или иначе создавать, но физически рисовать ничего не по требуется (под вопросом остается необходимость в полноэкранном режиме, в windows это критично, советую начать изучение с этого момента, приложения в оконном режиме могут не синхронизироваться с монитором по простому, но могут в принципе, ведь как то это делают видеоплеером и браузеры с их видеоплеером, и там опять будут нюансы по кросплатформенности, ведь не на каждом сетапе в linux это в принципе работает, tearing это беда)

[Dyikot]

rPman, Буду иметь в виду. Буду решать проблемы по мере их поступления.