Easiest way to signal an event to several processes in .NET

Question

I was hoping there was an easy way to signal an event to several processes that did not involve me writing a custom socket listener. I'm trying to inform several applications that will need to update their cached configuration settings that a config change has occurred. I wanted to implement a "host wide" singleton, but have failed to find any examples. Is such a thing even possible?

Answer 1

Named semaphore and Named mutex are used for interprocess synchronization.

Msdn says:

Semaphores are of two types: local semaphores and named system semaphores. If you create a Semaphore object using a constructor that accepts a name, it is associated with an operating-system semaphore of that name. Named system semaphores are visible throughout the operating system, and can be used to synchronize the activities of processes.

Msdn says:

Named system mutexes are visible throughout the operating system, and can be used to synchronize the activities of processes. You can create a Mutex object that represents a named system mutex by using a constructor that accepts a name. The operating-system object can be created at the same time, or it can exist before the creation of the Mutex object.

Hope this helps

Answer 2

You can use cross-process wait handles. Check out this excellent threading tutorial for more information.

You could use the wait handles in a singleton class to create a sort of host wide singleton. Here is everything you need to know about the singleton pattern in C#.

One possible implementation: the singleton could represent the configuration settings. Before retrieving a setting, you could check the time stamp on a file that stores the cached configuration settings. Read/write access to the file could be protected by wait handles.

If you are averse to using wait handles, you could set a time stamp in the registry. Getting and setting registry values are atomic operations, so they are automatically thread-safe. Be aware, though, that this requires registry permissions, so it may be undesirable unless you can be sure your users have the requisite privileges.

Answer 3

You can use a named EventWaitHandle. However, you'd also need some way to reset the event after all of the processes listening were notified. You can probably do something like set the event and then reset it after some short period of time: one second or five seconds. Clients could know that the event won't trigger that quickly in succession.

Another possibility is to use a named Semaphore. But then you need to know how many listeners there are so that you can set the Semaphore's initial and maximum values.

There are ways to do what you're asking without having to build anything fancy.

Answer 4

For tightly coupled publisher/subscriber model (where the publisher is explicitly aware of all subscribers):

• You can use a semaphore set by the publisher and have all subscribers wait on it. However, if any of the subscribers dies, your count will be thrown off. You will need to implement some form of a zombie detection

• You could use COM connection points. This requires admin registration of the COM classes and type libraries.

For loosely coupled publisher/subscriber model (where the publisher doesn't know anythig about the subscribers):

• If you configuration settigns are kept in a file or in the registry, the subscribers can implement a file or a registry change listener. Unfortunately, this solution is limited to file/registry changes, does not scale and can be subject to delays based on the file system/registry load.

• You can use the COM+ Loosely Coupled Events (through System.EnterpriseServices). However, this could be an overkill for you due to the complexity of LCE.

• You can broadcast a window message that the publisher registered through RegisterWindowMessage to all hidden top-level windows of particular class. All subscribers will need to create one such window. This would require some Win32 interop, but is probably the most lightweight way to implement loosely coupled publisher/subscriber.