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

ВНИМАНИЕ! КОММЕНТАРИИ ПЕРВОГО УРОВНЯ В ВОПРОСАХ УПОРЯДОЧИВАЮТСЯ ПО ЧИСЛУ ПЛЮСИКОВ, А НЕ ПО ВРЕМЕНИ ПУБЛИКАЦИИ.
Есть ли разница между использованием функций WindowsAPI Sleep() и WaitForSingleObject() в плане эффективности предоставления оставшейся части кванта времени другим потокам?
Предположим, мы хотим приостановить текущий поток на малый промежуток времени (например, 50-100 мс), и, как перфекционисты, желаем, чтобы другим потокам досталась максимально возможная часть этого процессорного времени, включая остаток текущего кванта (минимизировать накладные расходы, присущие реализации).
Точность реализации временной задержки не имеет значения

Вариант 1: Sleep(xx)
Вариант 2: WaitForSingleObject(h,..,..,xx) — в качестве хендла указываем хэндл самого потока, соответственно выход по таймауту
avatar
Sleep() эффективнее, т.к. он дополнительно понижает приоритет вызывающего потока. WaitForSingleObject() этого не делает.
avatar
bstone, понял, спасибо
avatar
Дед Нечипор, если поток ждет (ничего не делает), то, наверное, у него в любом случае будет низкий приоритет. Тут, скорее, вопрос в дизайне: если поток не ждет определенного события, то чего он, собственно, ждет? Может, когда истечет таймер будет не лучший момент для исполнения с точки зрения загруженности процессора. Может, лучше изначально исполняться с заведомо низким приоритетом или подождать пока более важные «разрешат»?
avatar
Value, тут ситуация такая: есть потоки-поставщики маркет-данных и потоки-потребители. Соединены lockless очередями. И у тех, и у других предполагается наличие постоянной работы по определению, поэтому вклинивать в процесс отправки данных сигнализацию с помощью TEvent считаю неоправданной в моем случае, т.к. добавляются накладные расходы на синхронизацию.
     Предполагаю, что время «простоя» (промежуток времени, когда очередь пустая или промежутки между доставкой датафидом данных потоку-поставщику для постановки в очередь) можно ожидать слишком малой величиной и сами простои не таким уж и частым событием, чтобы проектировать это взаимодействие на событийной модели через объекты синхронизации.
    Решил пойти таким путем — если вдруг так уж случилось, что выдался момент затишья у потока, то нечего впустую молотить процессорное время и дать потоку заснуть на малый квант времени (50-100 мс), эдакая подсказка планировщику, что можно подкормить временем другие потоки, может кому нужнее. С миру по нитке — гляди, и еще на один поток-робот время наскребется на бюджетном процессоре. А пакет датафида, который накопится за это время, будет обработан позже — задержка-то некритична.
avatar
bstone, а пониженный приоритет у потока остается после возврата из спячки, или возвращается к обычному состоянию, предшествующему засыпанию? Т.е. если все потоки имели равный приоритет, останется ли это так же после того, как один из них (или каждый в свое время) вызовет и вернется из Sleep()?
avatar
Дед Нечипор, Sleep() понижает приоритет потока до базового и так его и оставляет. Т.е. если менялся динамический приоритет потока для priority boost, то его после спячки надо будет опять поднимать по необходимости.
avatar
bstone, спасибо
avatar
Это все не работает на малоядерных процессорах под виндовс, типичный слип будет 2-6 миллисекунд при переключении контекста процесса. На него и можно закладываться.
avatar

Только зарегистрированные и авторизованные пользователи могут оставлять ответы.

Залогиниться

Зарегистрироваться

теги блога Дед Нечипор

....все тэги



UPDONW
Новый дизайн