I would seriously question your general architecture. Isn't it much better to run it all in one process? This way, you could still execute what should be executed in parallel in different thread and synchronize them using .NET thread synchronization primitives.
First of all, please note that it does not compromise modularity of the solutions or can even improve them. Separate assemblies referencing each other and loaded by the same process make better modules than separate processes, which are well isolated. As to the synchronization of separate processes, this is quite possible, if you program these processes to participate in such collaboration. This approach has apparent drawbacks though:
- Synchronization creates bigger overhead in system memory usage and execution time.
- Synchronization objects work as different object in address spaces of a separate processes, as those address spaces are isolated. To use of identical synchronization objects in different processes requires naming of them. And it requires creation system-unique names (atoms). This is a separate hassle: you will need to guarantee uniqueness of the names and probably handle the cases when uniqueness is failed, because, due to some coincidence, some other unrelated process already created the identical atom. This way, the apparently simple approach where the assembly share some hard-coded atom names defined in some shared assembly may fail. It's pretty difficult to avoid such clashes with 100% guarantee.
- Support of the solutions based on such approach is more difficult.
- Debugging of the solution based on multiple processes is considerably more difficult than with a single-process multi-threaded solution.
Unfortunately, I am not familiar with detail of your architecture and your ultimate goals. So, I cannot advise a final solution.
Therefore, I still can imagine that the multi-process solution may be required by whatever reasons. You still can do synchronization in .NET projects. For example, let's consider the use of
mutex, something which you would use in most typical cases. Please see:
http://en.wikipedia.org/wiki/Mutex[
^],
http://msdn.microsoft.com/en-us/library/system.threading.mutex.aspx[
^].
A light-weight unnamed mutex will not work across different process. (Going back to threads: the synchronization would require even more simple and robust device than a mutex: a lock statement,
http://msdn.microsoft.com/en-us/library/c5kehkcz.aspx[
^].)
You will need to use
Mutex constructors with a string parameter used to pass name. You try to create new or already existing instance of
Mutex by name. An instance can already exist if some other process created one under the same name. After creation and instance, you can learn if it is new or not, from out parameter (please see two last references to the constructor help pages below). So, you will need to use on or more of the following constructors:
http://msdn.microsoft.com/en-us/library/f55ddskf.aspx[
^],
http://msdn.microsoft.com/en-us/library/bwe34f1k.aspx[
^],
http://msdn.microsoft.com/en-us/library/9zf2f5bz.aspx[
^].
—SA
Submit an article or tip