Здравствуйте, LimyKurn, Вы писали:
LK>Надо просто переделать архитектуру.
LK>Непосредственно в каллбеке вообще не надо ничего делать. Надо только получать текущее системное время и создавать поток, в который передавать время и параметры операции. Каждый вызов каллбека = новый поток.
LK>Ну, а в этом потоке уже гораздо менее критично время выполнения. Можно использовать любые типы синхронизации с отдельным потоком-writerом. А можно просто заставить эти потоки выполняться последовательно. И делать write прямо здесь же, а не в еще одном отдельном потоке.
LK>Можно запускать гигабайтные тесты, — тест отрабатывает, в лог валится куча записей, но время выполнения не вырастает ни на миллисекунду. Ведь создание потока почти ничего не стоит.
LK>А как вам?
На мой взгляд, затея так себе. Объясню почему.
* Создание потока (PsCreateSystemThread) — это достаточно дорогая операция. Не знаю, откуда ты взял,
что "создание потока почти ничего не стоит". Нужно создать и проинициализировать объект ядра, создать для
него хэндл, заполнить кучу всяких системных структур, поместить новый объект во всевозможные списки и т.д.
* Между функцией потока и менеджером фильтров (FltMgr) не будет никакой синхронизации.
А она нужна. Например, для безопасного выполнения teardown фильтра.
* Не всегда из post-калбэка вообще допустимо создавать поток и откладывать выполнение I/O-операции.
См. примечание к функции FltQueueDeferredIoWorkItem:
The I/O operation cannot be posted safely to a worker thread. Possible reasons include the following:
FltQueueDeferredIoWorkItem cannot post an I/O operation to a worker thread if the TopLevelIrp field of the
current thread is not NULL, because the resulting file system recursion could cause deadlocks or stack overflows.
(For more information, see IoGetTopLevelIrp.)
FltQueueDeferredIoWorkItem cannot post a paging I/O operation to a worker thread.
Ну и последнее. Как ты будешь создавать поток в post-калбэке, если там IRQL может быть APC_LEVEL/DISPATCH_LEVEL, а
PsCreateSystemThread требует PASSIVE_LEVEL?
LK>А какого-то другого потокобезопасного контейнера, который бы не был связным списком, в NT просто нет.
RtlInitializeGenericTableAvl с синхронизацией через спинлоки. Чем не вариант?
