Распределяемая память

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

 

А теперь тоже самое по-русски.

 

у меня чото сразу возникло чувство, что ТС надо про разделяемые секции/маппинг чтото

 

У меня тоже. Но я не понял че конкретно)

 

конкретно. допустим имеем 2 программы. у них есть разделяемая память(например изменяем значения переменой в одной, меняется и в другой). Аналог юниксовых shmget,shmat...

 

CreateFileMapping/MapViewOfFile
или более низкоуровнево
ZwCreateSection/MapViewOfSection

 

ZwMapViewOfSection*

 

если я правильно понял описание эти функции работают с файловой системой?

 

и с ней тоже.. но это именно то, что вам необходимо

 

спасибо, но надо бы както без ФС, просто участок памяти ОЗУ доступный всем процессам.
у меня была мысль создать сегмент и поместить его дискриптор в GDT, если это вообще возможно ...?

 

bolt90
Во первых память подкачиваемая практически вся в юзермоде, исключая разве что PEB, US. Залочивание не гарантирует отсутствие выгрузки в своп, оно лишь такую вероятность снижает. Код на первых двух IRQL обычно подкачку и не заметит, для чего вообще нужно это ?

 

bolt90

Не совсем. Во-первых, в винде вся виртуальная память связана с файловой системой, т.к. при необходимости любые данные могут быть сброшены на диск и загружены обратно в память. Во-вторых, если в CreateFileMapping задать hFile = INVALID_HANDLE_VALUE, то данные будут "проецироваться в файл подкачки", что на деле означает - будут сидеть в памяти пока рак на горе не свистнет

 

Clerk
сравнение функционала с юниксом

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

 

bolt90

Не пойму, что тебя смущает ? Отсутствие простой\красивой функции-обертки под названием shmget или факт реализации разделяемой памяти через FileMapping ? Если второе, то уже пояснили, что в винде вся виртуальная память основана на подкачке, и разделяемые системные dll проецируются в разные процессы через маппинг. Спрашивается - зачем создавать еще какой-то особый доп.механизм создания разделяемой памяти между процессами, если он уже есть.
Ну а то, что мелкософты поленились завернуть пару функций CreateFileMapping+MapViewOfFile в красивый фантик типа shmget - считай, что это их маркетинговый "прокол", недостаточный "функционал" и т.п.

 

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

 

bolt90

Да с чего ты взял, что "файл" - это обязательно жесткий диск. Например, виндусовый рисунок metafile - это что, файл на диске (как многие ньюбы считают) или просто структура записи с последовательным доступом ?! О понятиях "файловый\системный кэш", "упреждающее чтение", "ленивая запись" и т.п. слышал ? В описание флага FILE_FLAG_TEMPORARY CreateFile заглядывал ? Винда, несмотря на "отдельные недостатки", устроена достаточно умно, по принципу "не чеши пока не чешется" - пока есть свободная физ.память обмен с диском сводится к минимуму. Поэтому свопинг памяти, выделенной CreateFileMapping(-1,..), ничем не отличается от свопига "обычной" памяти, выделенной VirtualAlloc, т.к. в отношении них действует общий механизм работы с виртуальной памятью

 

bolt90
CreateFileMapping (ZwCreateSection) смотри описание. вместо hFile можно передать INVALID_HANDLE_VALUE, тогда оно спроецирует потом через MapViewOfFile(Ex)/ZwMapViewOfSection файл подкачки.

 

Great
Если в обьекте секция FilePointer не задан, то возможно что не будет свопиться, но точно не знаю. Аналогично если промапить секцию физиклмемори. Хотя я не уверен.

 

Ему будет достаточно маппинга пейджфайла
А в любом случае потом можно сделать VirtualLock и свопиться ничего не будет

 

А еще есть одна dll для разных процессов, физически находящаяся в памяти один раз, для экономии памяти