C>Искусственные лимиты полезны — мы можем дать гарантию, что запрос обработается максимум за N секунд, если он таки был принят на исполнение. Если же у нас нет лимита — возможна ситуация, когда очередь будет расти неограничено.

Если у вас просчитаны времена худшего случая для абсолютно всех стадий исполнения, в т.ч., например, время дергания головкой в диске вместе с ее возможной тепловой рекалибрацией, и с учетом других процессов, которые тоже оной головкой дергают (Content Index, например, или да мало ли что там еще в ОС живет)- то да.

Но это ну крайне сложно, а в не-риалтаймовой ОС — невозможно, хотя бы потому, что вашу нить может прервать еще что-то (UI например, а то и вовсе скрин-сейвер) — и прервать зачастую на значительное время.

Ну или, например, возможные потери пакетов в сети и ретрансмиты. Не думайте, что пакеты теряются только от плохого контакта в проводах — в проводных сетях первая причина потери пакетов — перегрузка раутеров по пути, и именно на эту причину и затюнингован алгоритм slow start/congestion avoidance в TCP.

Короче, дать гарантию худшего времени исполнения в не-риалтаймовой ОС — невозможно, и резать ресурсы ради дачи такой "якобы гарантии" — бессмысленно.

Что же касается попыток дать такие гарантии в, например, системах на базе SQL — то можно, я грустно улыбнусь?

C>За такие хаки я бы лично ногами бил разработчиков. Код должен работать на максимум пропускной способности.

Постойте, а зачем тогда лимиты?

C>Ограничивать ее — дело операционной системы (планировщиков IO,

В какой это ОС у нас есть планировщик дискового IO? в виндах до Висты не было никакого, был только elevator seek и использование SCSI tagged queue, да и в Висте какой-то убогий.

C>процессора, сети — они лучше свою работу знают).

А вы никогда не встречались с требованием "ограничить сетевой трафик, создаваемый системой"? или "ограничить disk IO трафик, создаваемый системой"?

Совершенно запросто под виндами можно написать приложеньице, которое забьет дисковый IO так, что подвиснет shell UI на первом же page fault в shell32.dll или explorer.exe. Юзеры этого не любят.

Вот для реализации этих требований и делают ReadFile+Sleep, что есть полная эмуляция более медленного диска (особенно если нить высокоприоритетна).

C>Такие sleep-хаки могут привести к паталогическим случаям, если две программы будут просыпаться в одно и то же время — они будут обе считать, что процессор загружен на 100%.

С загрузкой _процессора_ тут надо быть осторожнее, это да, для нее лучше GetThreadTimes использовать — сколько времени бежала именно данная нить на процессоре.