Являются ли 16 миллисекунд необычно большим временем ожидания выполнения незаблокированного потока, работающего в Windows?

Недавно я выполнял некоторые глубокие проверки времени в приложении DirectShow, которое у меня есть в Delphi 6, используя компоненты DSPACK. В рамках моей диагностики я создал класс Critical Section, который добавляет функцию тайм-аута к обычному объекту Critical Section, присутствующему в большинстве языков программирования Windows. Если время между первой Acquire() и последней совпадающей Release() превышает X миллисекунд, генерируется исключение.

Первоначально я установил тайм-аут на 10 миллисекунд. Код, который я завернул в Critical Sections, работает довольно быстро, используя в основном перемещение и заполнение памяти для большинства операций, содержащихся в защищенных областях. К моему большому удивлению, я получил довольно частые тайм-ауты в, казалось бы, случайных частях кода. Иногда это происходило в блоке кода, который итерирует список буферов и последовательно выполняет определенные быстрые операции, иногда в крошечных участках защищенного кода, который выполнял только очистку флага между вызовами Acquire() и Release(). Единственная закономерность, которую я заметил, заключается в том, что длительность, обнаруженная в момент тайм-аута, была сосредоточена на среднем значении около 16 миллисекунд. Очевидно, что это огромное количество времени для установки флага в последнем примере события, о котором я упоминал выше.

Итак, мои вопросы:

1) Возможно ли, чтобы код управления потоками Windows довольно часто (примерно раз в несколько секунд) отключал незаблокированный поток и не возвращался к нему в течение 16 миллисекунд или дольше?

2) Если это разумный сценарий, какие шаги я могу предпринять, чтобы уменьшить количество таких случаев, и следует ли мне подумать о повышении приоритетов потоков?

3) Если это не разумный сценарий, что еще я должен рассмотреть или попробовать в качестве метода анализа, чтобы диагностировать реальную проблему?

Примечание. Я использую Windows XP на четырехъядерном процессоре Intel i5 с 3 ГБ памяти. Кроме того, причина, по которой мне нужно быть быстрым в этом коде, связана с размером буфера в миллисекундах, который я выбрал в своих графиках фильтра DirectShow. Чтобы свести задержку к минимуму, аудиобуферы на моем графике доставляются каждые 50 миллисекунд. Поэтому любая операция, которая занимает значительный процент этого времени, вызывает беспокойство.