Kernel -> User коммуникация

x64
Тот факт, что используется захват двух мьютексов, приводит к верованию в то, что приведённое в статье место является не единственным, требующим защиты. И на самом деле – другие защищаемые места не такие краткие. Тем не менее, путь высказывания понятен теперь.

TSS
Насчёт оверхеда. В случае, если примитив будет занят при попытке захвата, но практически гарантировано, что он освободится спустя несколько мгновений, то, возможно, выгоднее будет покрутиться, нежели пытаться войти в ожидание на объекте диспетчера.

Clerk
>>DirectIO
>Это реализуется открытием IOPM для пользовательского кода(R3). Зачем оно?
В данном случае под "DirectIO" мы подразумевали метод передачи данных между приложением и драйвером – METHOD_XXX_DIRECT. (Была дана фраза "Можно DMA использовать, вместо буферизированного ввода\вывода" – а поскольку использования DMA для общения драйвера с пользовательским приложением делает мало смысла, но в качестве контекста были установлены IOCTL-запросы и в фразе было явное противопоставление относительно METHOD_BUFFERED – то было распознано понятийное расхождение, после чего мы решили сделать поправку в целях улучшения прозрачности топика [хотя необходимо заметить, что ущерб от данного предложнения почти полностью это нивелирует]).

 

Sol_Ksacap
Представьте себе хорошо загруженный работой процессор, стопицот потоков бегающих на нем делают свою работу, и тут приходите вы, и с PASSIVE_LEVEL'а берете и задираете до DISPATCH, хватая спинблокировку. Все эти потоки прекращают делать свою работу, и ждут пока барин освободит спинблокировку, чтобы продолжить. Все же почитайте, что микрософт пишет в доке по синхронизации, они дело говорят, к гадалке не ходи Может быть конечно в отдельно взятом случае будет какой-то выигрыш( неплохо было бы увидеть некие цифири показывающие профит от юзания спинлоков в этом случае ), но думается, стоит следовать рекомендациям микрософт, касательно примитивов синхронизации.

 

TSS

Objection! .D
Сотни потоков не бегут – бежит только наш единственный поток. На других [логических] процессорах – да, там другие потоки, но на их бег мы поднятием IRQL на своём процессоре не влияем – во всяком случае они свою работу делать не прекращают. Да, поставить другой поток на этот процессор, а также на процессоры, пытающиеся овладеть спинлоком в этот момент, не выйдет – но в ситуации со сверхкоротким временем удержания не так уж и важно, что процессор, исполняющий _наш_ поток, будет недоступен для других потоков несколько мгновений – в конце концов, _наш_ поток делает в эти мгновения полезную работу. А недоступность других процессоров в каких-то редчайших случаях конкуренции не продлится и десятка-другого тактов. При использовании же быстрых\охраняемых мьютексов в такой же ситуации в тех же редчайших случаях конкуренции другие потоки могут начать вхождение в длинный путь перепланировки – что фактически потребует много больше времени, чем пара десятков тактов, необходимых для выполнения нашим потоком защищённого кода.
Хотя то, что безконкурентный захват _охраняемого_ мьютекса на x32 требует меньше времени, чем безконкурентный захват _быстрого_ мьютекса или спинлока – из-за отсутствия поднятия IRQL – делает некоторое изменение весов.

Стоит объявить, что мы делаем понимание незаменимости примитивов вроде охраняемых мьютексов в общем случае; также делаем понимание, что обрисованная ситуация весьма сферична и реальное поведение и быстродействие глубоко зависят от совокупности множества условий. (Кроме того, оговорка: белую бумагу про волосы, мёртвые волосы и послевремённость мы читали, код примитивов смотрели, но замеров не делали).

Очень превосходно, мы далеко за темой топика теперь.

 

Sol_Ksacap
DMA значит.. вобще бред пишите какойто.

 

Sol_Ksacap
Я к тому, что мы не в юзермоде находимся, там даже если мы зарвемся - ничего страшного не произойдет, даже самый захудалый поток получит квант времени для себя, в ядре же поправить нас некому и захватывая спинблокировку мы поступаем очень эгоистично по отношению к остальным потокам(тут стоит рассмотреть ненулевую вероятность ошибки в нашем коде которая приведет к...). Вобщем я понял вашу точку зрения, и все же я протев =] И да, это все флейм по сути, я закругляюсь.

 

Всем откликнувшимся - Большое Спасибо!

Задач в том, чтобы передать строку с кернела в мое приложение. Хочу реализовать механизм передачи, так, чтобы не сохранять строки в драйвере (а их количество, с работой драйвера, будет увеличиваться), а сразу передавать в юзермод. Ну и потом уже быстродействие.

Вот выбрать лучший вариант не могу.

 

Ты можешь драйвером записать свою строку в разделяемую область памяти и моргнуть ивентом. Приложение увидит, что данные готовы и заберет их на обработку.

Если же задача состоит в том, чтобы передать строку по запросу от приложения, то есть еще более быстрый способ.

 

Я скорее всего остановлюсь на варианте с разделяемой памятью и евентами. Большое Всем Спасибо!