Question

I’ve seen a project where communication between processes was made using shared memory (e.g. using ::CreateFileMapping under Windows) and every time one of the processes wanted to notify that some data is available in shared memory, a synchronization mechanism using named events notified the interested party that the content of the shared memory changed.

I am concerned on the fact that the appropriate memory fences are not present for the process that reads the new information to know that it has to invalidate it’s copy of the data and read it from main memory once it is “published” by the producer process.

Do you know how can this be accomplished on Windows using shared memory?

EDIT
Just wanted to add that after creating the file mapping the processes uses MapViewOfFile() API only once and every new modification to the shared data uses the pointer obtained by the initial call to MapViewOfFile() to read the new data sent over the shared memory. Does correct synchronization require that every time data changes in shared memory the process that reads data must create MapViewOfFile() every time ?

Answer 1

If you use a Windows Named Event for signaling changes, then everything should be OK.

Process A changes the data and calls SetEvent.

Process B waits for the event using WaitForSingleObject or similar, and sees that it is set.

Process B then reads the data. WaitForSingleObject contains all the necessary synchronization to ensure that the changes made by process A before the call to SetEvent are read by process B.

Of course, if you make any changes to the data after calling SetEvent, then these may or may not show up when process B reads the data.

If you don’t want to use Events, you could use a Mutex created with CreateMutex, or you could write lock-free code using the Interlocked... functions such as InterlockedExchange and InterlockedIncrement.

However you do the synchronization, you do not need to call MapViewOfFile more than once.