Вопрос к программистам по WinAPI. Sleep(xx) или WaitForSingleObject?

вопрос торговые роботы

Дед Нечипор

северный полюс Земли

595

с 28 марта 2015

9 Комментариев

Комментарий закреплён
Дед Нечипор
27 октября 2022, 17:41
Есть ли разница между использованием функций WindowsAPI Sleep() и WaitForSingleObject() в плане эффективности предоставления оставшейся части кванта времени другим потокам?
Предположим, мы хотим приостановить текущий поток на малый промежуток времени (например, 50-100 мс), и, как перфекционисты, желаем, чтобы другим потокам досталась максимально возможная часть этого процессорного времени, включая остаток текущего кванта (минимизировать накладные расходы, присущие реализации).
Точность реализации временной задержки не имеет значения

Вариант 1: Sleep(xx)
Вариант 2: WaitForSingleObject(h,..,..,xx) — в качестве хендла указываем хэндл самого потока, соответственно выход по таймауту

0
bstone
27 октября 2022, 17:40
Sleep() эффективнее, т.к. он дополнительно понижает приоритет вызывающего потока. WaitForSingleObject() этого не делает.
+1
- Дед Нечипор
  27 октября 2022, 17:43
  bstone, понял, спасибо
  0
  - Value
    28 октября 2022, 17:06
    Дед Нечипор, если поток ждет (ничего не делает), то, наверное, у него в любом случае будет низкий приоритет. Тут, скорее, вопрос в дизайне: если поток не ждет определенного события, то чего он, собственно, ждет? Может, когда истечет таймер будет не лучший момент для исполнения с точки зрения загруженности процессора. Может, лучше изначально исполняться с заведомо низким приоритетом или подождать пока более важные «разрешат»?
    +1
    - Дед Нечипор
      28 октября 2022, 17:12
      Value, тут ситуация такая: есть потоки-поставщики маркет-данных и потоки-потребители. Соединены lockless очередями. И у тех, и у других предполагается наличие постоянной работы по определению, поэтому вклинивать в процесс отправки данных сигнализацию с помощью TEvent считаю неоправданной в моем случае, т.к. добавляются накладные расходы на синхронизацию.
      Предполагаю, что время «простоя» (промежуток времени, когда очередь пустая или промежутки между доставкой датафидом данных потоку-поставщику для постановки в очередь) можно ожидать слишком малой величиной и сами простои не таким уж и частым событием, чтобы проектировать это взаимодействие на событийной модели через объекты синхронизации.
      Решил пойти таким путем — если вдруг так уж случилось, что выдался момент затишья у потока, то нечего впустую молотить процессорное время и дать потоку заснуть на малый квант времени (50-100 мс), эдакая подсказка планировщику, что можно подкормить временем другие потоки, может кому нужнее. С миру по нитке — гляди, и еще на один поток-робот время наскребется на бюджетном процессоре. А пакет датафида, который накопится за это время, будет обработан позже — задержка-то некритична.
      +1
- Дед Нечипор
  28 октября 2022, 17:16
  bstone, а пониженный приоритет у потока остается после возврата из спячки, или возвращается к обычному состоянию, предшествующему засыпанию? Т.е. если все потоки имели равный приоритет, останется ли это так же после того, как один из них (или каждый в свое время) вызовет и вернется из Sleep()?
  0
  - bstone
    28 октября 2022, 17:33
    Дед Нечипор, Sleep() понижает приоритет потока до базового и так его и оставляет. Т.е. если менялся динамический приоритет потока для priority boost, то его после спячки надо будет опять поднимать по необходимости.
    +2
    - Дед Нечипор
      28 октября 2022, 17:43
      bstone, спасибо
      0
Denis
27 октября 2022, 18:05
Это все не работает на малоядерных процессорах под виндовс, типичный слип будет 2-6 миллисекунд при переключении контекста процесса. На него и можно закладываться.
+1