I feel you're confused. You're trying to work with
Mutex
where
Event
should be used. Here is the idea:
AwakeOfSomething
should be just a call to
SetEvent
, next operation depends on the
Event
option (
manualReset
or not), so you many need
ResetEvent
or not.
The
Mutex
is a very different beast. You should limit it application to only one: mutual exclusion (very informative phrase, isn't it :-)?). As a rule of thumb, you need a mutex per each shared data structure (not a formal structure, but some set of object supposed to keep atomicity). Every access of such structure should be sandwiched be a mutex. You can nest mutexed block, but guarantee it is always releases. For this purpose, you need to put all you do after taking a mutex in "try" block and release a mutex always in "finally" block. If you always work through a process boundary, your mutexed data is in the Shared Data.
Mutexes and Events should not intercept functionality. Also, you data can effectively be serialized be Events along. You need to calculate very accurately if the Mutexes are redundant or not. In difficult case, use Petri net formalism.
Now, I don't know exactly if you exchange data between you components. Chances are, you need a blocking data queue. I can give you an idea how it works (via
Event
objects which are called
EventWaitHandle
in .NET). Sorry my CodeProject code is in C#, it will give your an idea anyway:
Simple Blocking Queue for Thread Communication and Inter-thread Invocation[
^].
Now, for the transport part you can use named pipes, because you work through the process boundary. In this case, don't use Shared Memory, use pipes instead.
Finally, there is a secret weapon which can replace both. This is Socket API! Did you know they were originally designed as the IPC for the same machine, even before IP was used. You still can use sockets on a single machine as just an IPC tool. This thing in my favorite.
It was just a skeleton. I cannot go in further detail right now, because I don't know you application detail to offer the only solution. By the same reason I don't go into API references: you can find it all by my keywords. You're welcome to ask follow-up Questions (please, don't post them as Answers, a common and annoying mistake!), especially if you provide more information and explain your ultimate goals.
—SA