1

I'm trying to write a code that's a very simple single process server with a single client. These are separate programs as I'm trying to eliminate compiler-compatibility issues between the tools. Eventually, I intend to allow multi-threading, but that's just a step too far as I try to get the hang of this. I have something that works using Windows Events, but I'm trying to get away from it as there's no direct equivalent on Linux as far as I can tell.

The server is supposed to execute a code when demanded by the client. The I/O between the two processes is via shared memory. Right now, I have events for initialization, execution, and termination. After the server receives the event, it sends a completion event back to the client notifying it to go on to the next task. There is no expectation that this will expand beyond a single machine.

I have it in my head that mutex may be the way to go, but I am creating a racing problem, I believe, as I can't get the server to get out of the way and wait for the client. I have the server creating the mutex but then I want it to release it and wait for the client to use it before coming back to the server to do something. Instead, the server just keeps getting the mutex, and while I can understand why, I just can't figure out any sort of solution.

The following test code I think highlights the issue.

#include <windows.h>
#include <stdio.h>
#include <conio.h>
#include <tchar.h>

int _tmain(int argc, char *argv[])
{
  int i = 1;

  // Create mutex
  HANDLE hMutex = CreateMutex(NULL, FALSE, TEXT("TESTMUTEX"));
  DWORD hResult;

  // Check valid hMutex

  while (i > 0)
  {
    // Wait for mutex
    // How do I make it wait for a connection here?
    hResult = WaitForSingleObject(hMutex, 1000);
    // Write note to screen
    printf("Received mutex!\n");
    // Wait for user to enter info
    scanf("%d", &i);
    // Release mutex
    if (!ReleaseMutex(hMutex))
    {
      printf("Mutex error!\n");
    }
    printf("Mutex Released!\n");
  }

  CloseHandle(hMutex);

  return 1;
}

This is just an infinite loop. The scanf is just sitting as a stand-in to allow me to pause and exit the test code. How do I get this to wait between the creation of the mutex and then where it's waiting for it in the loop? I think I need some way of saying that there's actually a client out there and to not wait for the mutex until there's a client connected (which would then allow the client to grab it, first). It's probably something obvious, but I'm rather new to IPC. Maybe I need to include sockets or pipes?

I haven't jumped into the client code beyond some dummy code, yet, as the server just isn't right, and shows enough of the problem (I think) without the client.

An example use case will involve Simulink S-Functions. I will have an engineering code (server) behind the scenes with multiple S-Functions (clients) running against it from a single Simulink model. The scanf in the test code is sitting in place of where the server will read the input, execute the code, and write back the output. This I/O is in shared memory so I can't have all of the processes writing and reading without locking the resource.

I think it's similar to this: Cross-Platform equivalent to windows events. The difference is that I have two completely separate programs instead of just the one.

Community
  • 1
  • 1
sr71pav
  • 137
  • 1
  • 10
  • A similar question has been asked. http://stackoverflow.com/questions/9711414/what-is-the-proper-way-of-doing-event-handling-in-c – Ian Jul 06 '16 at 19:02
  • I don't think you want a mutex here. A mutex is for protecting a resource. You release it right away so there won't be any blocking. Try looking into CreateEvent: https://msdn.microsoft.com/en-us/library/windows/desktop/ms682396(v=vs.85).aspx – Daniel Feryance Jul 06 '16 at 22:07
  • Daniel, my version with Events works fine. I'm trying to get away from that. Also, the mutex may come into play when I start having multiple instances running at some point in the future. I'm working on a single instance, now, but I intend to bring this to multiple instances once that works. This is proving the idea. – sr71pav Jul 07 '16 at 12:03
  • I still think you should stay away from a mutex. The way it handles locking a thread and abandonment isn't designed for how you want to use it. If you want something cross-platform, how about a pipe? Handles two-way communication, can be blocking or async, and you can pass whatever data you like. Otherwise a message queue would work but that is one-way. – Daniel Feryance Jul 07 '16 at 14:10
  • Would you consider this a good starting point on that? https://msdn.microsoft.com/en-us/library/windows/desktop/aa365780(v=vs.85).aspx – sr71pav Jul 07 '16 at 17:35

0 Answers0