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.
—SA
Submit an article or tip