Список проголосовавших за комментарий "Value, тут ситуация такая: есть потоки-поставщики маркет-данных и потоки-потребители. Соединены lockless очередями. И у тех, и у других предполагается наличие постоянной работы по определению, поэтому вклинивать в процесс отправки данных сигнализацию с помощью TEvent считаю неоправданной в моем случае, т.к. добавляются накладные расходы на синхронизацию. <br/> Предполагаю, что время «простоя» (промежуток времени, когда очередь пустая или промежутки между доставкой датафидом данных потоку-поставщику для постановки в очередь) можно ожидать слишком малой величиной и сами простои не таким уж и частым событием, чтобы проектировать это взаимодействие на событийной модели через объекты синхронизации.<br/> Решил пойти таким путем — если вдруг так уж случилось, что выдался момент затишья у потока, то нечего впустую молотить процессорное время и дать потоку заснуть на малый квант времени (50-100 мс), эдакая подсказка планировщику, что можно подкормить временем другие потоки, может кому нужнее. С миру по нитке — гляди, и еще на один поток-робот время наскребется на бюджетном процессоре. А пакет датафида, который накопится за это время, будет обработан позже