синхронизация при использовании shared memory

[Malaja]

Господа, у меня тормоз...

Дано:
а) основное приложение (MainApp)  и длл (DllApp), которая подгружается в основное приложение динамически
2) отдельная либа (UsedClasses), в которой находится класс (mainContainer), используемый обоими приложениями из а). При этом класс изобилует статическими объектами (и это уже не изменить - с этим надо жить)
3) если в основном приложении MainApp произошли изменения объекта типа mainContainer, то этот обновленный объект должен быть передан длл-лине, т.е. ее объект должен быть изменен ( т.о. у длл-лины будет копия объекта из MainApp). [ ну или наоборот - изменения в длл-лине д.б. переданы основному приложению]
4) Для того, чтобы иметь возможность копировать данные, решила применить shared memory (CreateFileMapping, OpenFileMapping, MapViewOfFile ).
Сразу же оговорюсь, я еще не знаю, будет ли это на 100% работать

Проблема:
Выяснилось, что после того, что в shared memory был создан файл и туда помещена инфа, файл нельзя закрывать, иначе при попытке считывания файл не находится.
Ладно, значит, надо как-то остановить функцию записи в файл до тех пор, пока оттуда не будет все считано.
Т.е.:

Код:

void DllTestClass::writeInSharedMemory()
{
   CreateFileMapping();
   MapViewOfFile();
   CopyMemory();

    !!!!!!!!!!!!!!!!!!
     вот тут надо как-то прерваться, пока получатель не считает данные:
     т.е. посадить блокировку, которую снимет получатель, и ждать, пока это 
     произойдет
    !!!!!!!!!!!!!!!!!
  
   UnmapViewOfFile(); 
   CloseHandle();
}


void readFromSharedMemory()
{
    OpenFileMapping();
    MapViewOfFile();
    CloseHandle(); // это уже спорно...

    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    тут снять блокировку
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!
}

Вопрос - как??? У меня уже полный тормоз...

[zubr]

1. Зачем вообще в данном случае расшаренная память. Ведь все происходит в рамках одного процесса. Указатель на выделенный блок памяти будет ликвиден в 3-х указанных модулях.
2. Синхронизацию можно делать через стандартные объекты синхронизации (события, семафоры, мутексы, критические секции):

Код:

   CreateFileMapping();//я бы это делал один раз при открытии приложения
   WaitForSingleObject();
   ResetEvent();
   MapViewOfFile();
   CopyMemory();
   UnmapViewOfFile();
   SetEvent(); 
   CloseHandle();//я бы это делал один раз при закрытии приложения

[Dimka]

Malaja, да, shared memory нужна, когда есть 2 и более процессов (exe), а все dll загружаются в то же адресное пространство, где работает процесс, поэтому достаточно передать банальный указатель.

[Malaja]

zubr, Dimka,

во-первых, спасибо! 
1) zubr, я вчера слету начала лепить мутекс, но поняла, что тут он не подходит. А про event забыла напрочь...

2) коллегу, подкинувшего задание, убью я ему сразу сказала, что все находится в одном адресном пространстве, посему никаких проблем быть не должно. Но он начал меня уверять, что я напрочь заблуждаюсь, что это не работает - он пробовал. И вообще, мол, когда я это делала в последний раз? Мда, а я этим таки занималась последний раз лет 5 назад, о чем ему и сообщила. Вот тут он мне и рассказал, что я все забыла, что не помню подробностей и мелочей, ну и т.д. ...
С учетом того, что он началъник и к тому же рассказал, что он уже пробовал, я ему предложила решение через расшареную память. Ну а раз предложила, то и начала выполнять. Ну и уткнулась в проблему с синхронизацией...

[zubr]

Malaja, у твоего коллеги по всей видимости руки кривые.
А зачем синхронизация вообще? MainApp и DllApp у тебя будут работать в разных потоках?

[Malaja]

zubr,
ты знаешь, так вроде бы были нормальные Я думаю, что у него что-то другое не срослось и в виде побочного эффекта не сработала передача данных, а он решил, что это и была основная проблема.

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

[zubr]

When the process no longer needs access to the file-mapping object, it should call the CloseHandle function. When all handles are closed, the system can free the section of the paging file used by the object.

MSDN
То есть объект файлового отражения не закроется пока все его открытые хендлы не будут закрыты. Отсюда вывод - хедлы расшаренной памяти закрывай при закрытии приложения и выгрузке длл.
Синхронизация нужна, если обращение к расшаренной памяти идет из нескольких процессов или потоков. То есть если к примеру один процесс что то записывает в память, а другой в это время что то читает - получится ерунда. В твоем случае синхронизация совершенно бессмысленна, так как, как я понимаю, все выполняется основном потоке приложения.

[Malaja]

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

В моем случае все это никому не нужно - надо работать с поинтерами.
Там будут другие приколы из-за наличия в классе кучи статических функций и переменных. Но это уже следующая стадия.

Еще раз всем спасибо!

[Антон (LogRus)]

.............Но он начал меня уверять, что я напрочь заблуждаюсь, что это не работает - он пробовал. ..........................

Дай ему в глаз.

вот на будующее
http://www.boost.org/doc/libs/1_42_0/doc/html/interprocess.html
если захочешь написать велосипед, то хотя бы будет, где подглядеть.
а так очень рекомендую, отказаться от своих велосипедов

[Malaja]

LogRus,
это указание я выполню в точности и с удоволствием ;_) Тем более, что вчера я уже это начала 
Т.е. я популярно объяснила товарищу, что я таки была права и нам хватит классических поинтеров.
Ну а с остальным надо будет разбираться - это уже мелочи.

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

[Антон (LogRus)]

Разобраться это дело хорошее
Но шансов, что я багов наделаю при реализации IPC ГОРАЗДО больше, чем при использовании чего-то написанного и покрытого автотестами (которые кстати тоже надо писать и поддерживать), у нас не пользуются своими реализациями довольно давно - слишком дорого, просто капец, проще один раз купить или взять открытое, чем тратить человеко-месяцы на поддержку
только сокеты напрямую используем, но они правда не настолько разные на Windows и Linux.