Synchronizing 2 processes using interprocess synchronizations objects - Mutex or AutoResetEvent

VitalyB picture VitalyB · Nov 8, 2010 · Viewed 17.9k times · Source

Consider the following scenario: I'm running my application which, during its execution, has to run another process and only after that 2nd process finishes inner specific initialization, can my first process continue. E.g:

...
// Process1 code does various initializations here
Process.Start("Process2.exe");
// Wait until Process2 finishes its initialization and only then continue (Process2 doesn't exit)
...

I see several options:

  1. Mutex - Mutex comes to mind automatically when considering interprocess communication, however, I can't see a way of causing Process1 to wait for a mutex that he generated himself. I can cause Process2 to create a mutex and wait on Process1 till the Mutex is created (using polling and Mutex.OpenExisting function)
  2. AutoResetEvent - Those would be perfect for the task, however, in seems that under .NET these can't be used for interprocess communcation.
  3. CreateEvent - I can use P/Invoke and use Win32 CreateEvent function. In theory, it could provide me with everything I need. I'd rather not using native functions, however, if possible.
  4. Use external file - The easiest way would be just to use some OS external object (file, registry, etc). However, this seems rather hacky, however.

I'd be happy to hear your opinion for this case.

Thanks!

Answer

Nicholas Miller picture Nicholas Miller · Mar 18, 2015

I was just going to edit this answer, but it doesn't seem correct. So I'll post my own...

According to the Threads for C# page, which has a lot of synchronization tutorials, AutoResetEvent cannot be used for interprocess synchronization.


However, a named EventWaitHandle can be used for interprocess synchronization. In the above page, visit the Creating a Cross-Process EventWaitHandle section.

The way you set this up is straight-forward:

Process 1

EventWaitHandle handle = new EventWaitHandle(
    false,                                /* Create handle in unsignaled state */
    EventResetMode.ManualReset,           /* Ignored.  This instance doesn't reset. */
    InterprocessProtocol.EventHandleName  /* String defined in a shared assembly. */
);

ProcessStartInfo startInfo = new ProcessStartInfo("Process2.exe");
using (Process proc = Process.Start(startInfo))
{
    //Wait for process 2 to initialize.
    handle.WaitOne();

    //TODO
}

Process 2

//Do some lengthy initialization work...

EventWaitHandle handle = new EventWaitHandle(
    false,                           /* Parameter ignored since handle already exists.*/
    EventResetMode.ManualReset,          /* Explained below. */
    InterprocessProtocol.EventHandleName /* String defined in a shared assembly. */
);
handle.Set(); //Release the thread waiting on the handle.

Now, regarding the EventResetMode. Whether you choose EventResetMode.AutoReset or EventResetMode.ManualReset depends on your application.

In my case, I needed a manual reset because I have have many processes connecting to the same process. So, once this same process is done being initialized, all of the other processes should be able to do work. Thus, the handle should be left in a signaled state (no reset).

For you, an automatic reset might be helpful if you have to perform initialization for every time process 1 starts process 2.


Side note: The InterprocessProtocol.EventHandleName is just a constant wrapped up inside a DLL that both process 1 and process 2 reference. You do not need to do this, but it protects you from mis-typing the name and causing a deadlock.