Cross-Process Mutex Read/Write Locking

Question

I'm trying to make inter-process communication in C/C++ on Windows environment.

I am creating a shared memory page file and two processes get the handle to that file. It's like this:

Process1: Initialize shared memory area. Wait for Process2 to fill it.

Process2: Get handle to shared memory area. Put stuff in it.

I am creating a named mutex in process1 as well. Now process1 acquires the ownership of the mutex soon after creating it (using WaitSingleObject). Obviously, there is nothing in the memory area so I need to release the mutex. Now I need to wait until the memory is filled instead of trying to acquire the mutex again.

I was thinking of conditional variables. Process2 signals the condition variable once it fills in the memory area and process1 will acquire the information immediately.

However, as per MS Documentation on Condition Variables, they are not shared across processes which is clear from their initialization as they are not named.

Furthermore, the shared memory area can hold up to one element at any given moment which means process2 cannot refill after filling it unless process1 extracts its information.

From the given description it's clear that condition variables are the best for this purpose (or Monitors). So is there a way around this?

Semaphores......... two semas, A,B, init to 0. P1 waits on A. P2 fills buffer. P2 signals A and waits on B. P1 handles buffer data then signals B and loops back to wait on A again. — Martin James, Nov 13 '17 at 18:24
@MartinJames I wanted to use them, but they do not work like condition variables. A mutex is essentially a semaphore with count set to one. I need to wait for signal rather than wait for ownership. If I used semaphores I will still get ownership just like with using the mutex. I don't want ownership until someone else signals me to. — Everyone, Nov 13 '17 at 18:28
'A mutex is essentially a semaphore with count set to one' no, not really. — Martin James, Nov 13 '17 at 18:28
@MartinJames I know it isn't exactly like that, but the way it works is very similar. Semaphores cannot fix my problem here. I looked them up before asking. — Everyone, Nov 13 '17 at 18:30
Two semaphores are EXACTLY the way to do what you describe. A queue with a length above 1 would need two semaphores and a mutex, (classic producer-consumer queue). You can get away with just the two semaphores that, effectively, swap around an 'access token' between just two processes. — Martin James, Nov 13 '17 at 18:35
@tambre Seriously? 1. How is it related? 2. There is C/C++, I am using standard C++ classes with C APIs. — Everyone, Nov 13 '17 at 18:35
@MartinJames Actually that makes a lot of sense. I will give it a try! Thanks! — Everyone, Nov 13 '17 at 18:36
@Everyone It's related to your tagging. C/C++ **is not** a language. Your code is in C++ and being compiled as such (from what I can tell). I'd consider the C tag unnecessary, as you're simply linking to the C APIs and the question isn't specifically about a problem of using such an API from C++ - the rest of your code is in C++. — tambre, Nov 13 '17 at 19:20
@tambre The term C/C++ is widely used since C codes are quite frequently used with C++. Yes, my code is essentially C++ and is compiled as such and it does make calls to C APIs which is why I used the term C/C++. Yes, the tag isn't necessary and I will remove it :) — Everyone, Nov 13 '17 at 19:23

score 1 · Answer 1 · answered Nov 13 '17 at 18:28

Conditional variables can be used with in the process, but not across the processes.

Try NamedPipe with PIPE_ACCESS_DUPLEX as open mode. So that you have communication options from both process.

https://msdn.microsoft.com/en-us/library/windows/desktop/aa365150(v=vs.85).aspx

score 0 · Answer 2 · answered Nov 13 '17 at 18:32

I have used events for this before. Use 2 named auto reset events. 1 data ready event and one buffer ready event. Writer waits for buffer ready, writes data and sets the data ready event. Reader waits for data ready event, reads memory and sets the buffer ready event. If done properly you should not need the mutex.

Cross-Process Mutex Read/Write Locking

2 Answers2