How to keep a Win64 C++ console app running like a service as it controls other executables? - windows

Question

I have a series of Win64 console apps, one is the "master" and 16 others are the "slaves".
The original version of this logic only had one executable, which when launched with a command line parameter "init" would initialize a very large data set (3gigs) and then sit on the Windows Message Pump waiting for messages requesting analysis of that large data set. When analysis of the data set is needed, that same executable is launched with analysis requesting parameters, and the newly launched executable would find the Window Handle of the already initialized instance of itself, and send the analysis request and parameters to the already initialized instance via the Windows Message WM_COPYDATA. This works like a charm for a single executable architecture.
However, now I have a more powerful system, and I want to run multiple analysis executables at once, each on a different core. So I made a new architecture where there are 16 analysis executables that act as "slaves" to a Manager console application which acts as "master". (FYI, one analysis request can take anywhere from 0.5 to 4.0 seconds - hence my desire to run multiples at once.)
Still using the Windows Messages as my communication means, use of SendMessage() blocks the caller until the message is handled by the receiver. That's no good, because I want these messages to be handled concurrently. So, I tried to use the asynchronous Windows Message functions, such as SendMessageCallback() and SendNotifyMessage(). They either failed or executed in a blocking manner, not concurrently.
More research led me to "Named Shared Memory" as a means of communicating between my executables (essentially a memory-mapped file). So I set that up, and my master is now able to create the Named Shared Memory block, and all my executables are able to request views of that same memory, and via a state machine handling of the data in the Named Shared Memory, I have synchronization between the master and the slaves.
HOWEVER, I am finding that the master and the slaves do not appear to be running continuously.
I'm still using the basic idea of the master is launched via a command line holding analysis parameters, that executable sends a message to the already running version of itself with the Named Shared Memory setup plus the current state of all the slaves, and then an available slave is selected and it's Named Shared Memory resident state machine gets the analysis request.
This portion is working fine. However, the slave(s) appear to be in a sleep or other dormant state, because my modified Windows Message Loop does not appear to be looping.
Here's what my current Windows Message handling loop looks like:
while (1) {
int status = ::GetMessage(&msg, 0, 0, 0);
if (status != 0) {
if (status == -1) return -1
::DispatchMessage(&msg);
}
else if (status == 0)
break;
HandleSharedMemoryDeliveredTasks(); // NOTE: checking Named Shared Memory
}
Placing a break point inside this loop does not get triggered unless a Windows Message is received.
So, I'm wondering how to keep my loop alive so the checking of Named Shared Memory continues without having to send a (blocking) message.
I aware that I'm operating in a problem space where I should convert my master and slave executables into Windows Services. However, I am very, very close to getting this working (it seems), and rewriting to a Windows Service is an area I have no experience.
Also, I am using this in my executables to keep them active (but it does not appear to be helping):
// during program init:
SetThreadExecutationState(ES_CONTINIOUS | ES_SYSTEM_REQUIRED | ES_AWAYMODE_REQUIRED);
Any suggestions how I can "wake up" a slave asynchronously when the master sets their state machine for work, and likewise have the slave "wake up" the master when the work is completed?