Click here to Skip to main content
15,846,211 members
Please Sign up or sign in to vote.
1.80/5 (2 votes)
See more:
I have a program that launches multiple processes at different points in its execution cycle. It starts then does something then shells out an .exe. But it has to wait until the exe is completed before it moves to the next step and then launches a different exe etc

What is the best way to synchronize this workflow (Observer pattern?)

What I have tried:

file locks but this is not very 'elegant'
Updated 12-May-16 6:52am

1 solution

The question makes no sense without knowing the application architecture, reasons for synchronization, and so on.

But, chances are, that this knowledge would reveal that the architecture has mistakes or should be reviewed by some other reasons. You see, not many people like to waste of something which does not have firm justification. The need for process synchronization is a pretty bad sign. Even for threads, the main rule of thumb should be: best synchronization is no synchronization. For processes, this is a clear call to review the architecture.

Indeed, file locks is a really bad way of synchronization, a wasteful one, to say the least. But don't get me wrong: there are cases when you really need an application in different processes and synchronization between processes, rarely. The idea is: some synchronization primitives can be used as named. Take the mutual exclusion problem. In one process, you can use one or another kind of lock (including usual lock statement), critical section or Mutex; and that mutex should be unnamed. However, using named mutex allows you to use it across processes: Mutex Class (System.Threading)[^].

Pay attention for the constructors with a name. This is the way to uniquely identify the mutex across processes. Unfortunately, it should be unique, which is always some problem.

This is just the idea. Without knowing your purpose and architecture, going into other detail related to IPC primitives makes no sense.

Another, a really good way of process synchronization, powerful and universal, is the use of sockets. Actually, initially sockets have been developed as a IPC tool; only later people developed sockets to work on a network. Please see:
TcpListener Class (System.Net.Sockets)[^],
TcpClient Class (System.Net.Sockets)[^],
a little lower level: Socket Class (System.Net.Sockets)[^].

Even better, you can use higher level for synchronization: "classical" remoting (many say it is obsolete, but it can be more convenient for synchronization purpose) or more modern WCF (self-hosted, of course). These technologies, in particular, allow you to abstract out the communication channels from the communication or synchronization logic. Imagine that later you want to synchronize processes on a network, even Internet — you will be able to change just the channels and their options in no time.

See also my past answers:
Communication b/w two Windows applications on LAN.[^],
how i can send byte[] to other pc[^].

So, my first step would be review of the architecture. First of all, one idea it to migrate from multiple processes to one, with threads. If the application runs on one machine (you did not say a word about distributed applications), it's a clear candidate for single-process application. It can be composed on many different assemblies and have plug-ins, but still in the same process. Unless you have a really convincing reason to have more than one.

Share this answer

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900