Как использовать блокированные операции x64 против MemoryMappedFiles в .net

Мне нужно использовать взаимосвязанные операции (CompareExchange, Increment и т. Д.) Против памяти в MemoryMappedFiles в .NET.

Я нашел этот ответ на очень похожий вопрос. Проблема в том, что заблокированные операции не экспортируются из библиотеки kernel32 (или любой другой) в 64-битной ОС (см., Например, http://blog.kalmbachnet.de/?postid=46).

Есть ли другой способ, как я могу вызвать заблокированные функции в блоке памяти в 64-битном процессе .NET?


person Jan    schedule 23.09.2014    source источник
comment
Я бы попытался написать свою собственную C Dll с экспортированными функциями, вызывающими заблокированные функции, и PInvoke из .NET.   -  person Alex F    schedule 23.09.2014
comment
@AlexFarber Отличная точка! Я просто хотел спросить об этом :) Вы случайно не знаете, могу ли я легко узнать, как ASM-реализация встроенных в компилятор заблокированных функций (например, http://msdn.microsoft.com/en-us/library/2ddez55b(v=vs.80).aspx) ? Чтобы мне не пришлось заново изобретать код ASM   -  person Jan    schedule 23.09.2014
comment
Вам не нужно этого делать, просто вызовите необходимые функции из нативной Dll, все остальное сделает компилятор. Я имею в виду, что для каждой связанной функции, которая вам нужна, напишите экспортированную функцию Dll, которая вызывает функцию Interlocked.   -  person Alex F    schedule 23.09.2014
comment
Смысл использования такой атомарной функции доступа состоит в том, чтобы встроить ее, чтобы минимизировать накладные расходы. Как только вам нужно установить pinvoke, эта точка полностью теряется, просто не остается смысла избегать именованного объекта синхронизации.   -  person Hans Passant    schedule 23.09.2014
comment
@HansPassant В моем случае я разделяю буфер памяти с сотнями длинных значений. Мне понадобятся сотни объектов синхронизации (мьютексы и т. Д.), Чтобы избежать конфликтов. Также я надеялся на Interlocked, поскольку они заставляют новое значение проталкиваться через строки кэша памяти (в отличие от барьеров памяти, которые имеют неопределенную синхронизацию) - но вы правы, что P / Invokes, скорее всего, полностью нарушат это преимущество: |   -  person Jan    schedule 23.09.2014


Ответы (1)


Напишите себе небольшую вспомогательную библиотеку C ++ / CLI, которая обеспечивает взаимосвязанные операции, потребляемые управляемым кодом.

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

person usr    schedule 16.10.2014
comment
К сожалению, это неверно - C ++ / CLI работает медленнее, чем P / Invoke с подавленными проверками - см., Например, здесь: codeproject.com/Articles/253444/ или здесь: xinterop. com / index.php / 2013/05/01 / Итак, P / Invoke - это то, что вам нужно (к сожалению, он по-прежнему отображает более десятка инструкций для каждого вызова) - person Jan; 04.11.2014
comment
Первая статья, кажется, показывает, что оболочка C ++ работает быстрее. Во 2-й статье оболочка C ++ работает намного медленнее, поэтому я начинаю подозревать. Возможно, не были включены оптимизации или была проделана дополнительная работа (действительно - оболочка C ++ вызывает sqrt только через промежуточный класс. Почему?). В обеих статьях время тестов было очень маленьким. Много шума. DateTime.Now тоже не очень точный. Обычно он увеличивается с шагом 15 мс. Его тесты были в диапазоне 10-30 мс. Я не доверяю ни одной из статей и не буду тратить время на дальнейшие исследования. - person usr; 04.11.2014
comment
Я согласен с вашими выводами. Суть в том, что если вам нужна максимальная скорость, вам нужно подавить все зондирование трассировки стека и т. Д., Связанные с управляемыми <-> собственными переходами. с помощью P / Invokes вы можете сделать это, указав атрибут SuppressUnmanagedCodeSecurity. С оболочкой C ++ / CLI вы получаете все эти проверки по умолчанию, и, насколько мне известно, вы не можете их сократить. - person Jan; 04.11.2014