Using Named events for inter process communication

Question

2.00/5 (1 vote)

See more:

I have a requirement to send notification events from Windows Service to a Windows console/Forms application using Named Events like Auto Reset Events and Manual reset events. For which I created a class library (WaitHandler) which has the definition for the Events. The windows client and service both have been reference by the class library in which the events are declared. The windows client waits at WaitOne() and the service need to raise an Set event so that windows client code can get into the loop. But When I try to raise the Set event, my client is not receiving it.

C#

public static class WaitHandler
    {
        private static System.Threading.ManualResetEvent manual = new     System.Threading.ManualResetEvent(false);
        private static System.Threading.AutoResetEvent auto = new   System.Threading.AutoResetEvent(false);

       public static System.Threading.AutoResetEvent GetAutoEventHandler()
       {
        return auto;
       }

    public static System.Threading.ManualResetEvent  GetManualEventHandler()
    {
        return manual;
    }
}

This is my code in Windows Service:

C#

public void RaiseEvent()
{
  WaitHandler.GetManualEventHandler().Set();
}

This is my code in Windows Client:

C#

public Form1()
   {
       InitializeComponent();
       new Task((o) => SubscribeToAsyncEvents(),
           new System.Threading.CancellationToken()).Start();
   }

   private void SubscribeToAsyncEvents()
   {
       while (true)
       {
           if (WaitHandler.GetManualEventHandler().WaitOne())
           {
               Console.WriteLine("Received Event");
               WaitHandler.GetManualEventHandler().Reset();
           }
       }

   }

Thanks

Posted 11-Apr-15 13:52pm

CSharpNewbie 2

Add a Solution

Comments

[no name] 12-Apr-15 3:52am

I agree with SA. The statement that this method is a requirement is absurd (in the formal sense). The requirement is the outcome not the methodology. Named pipes are also a well tried method of IPC. https://msdn.microsoft.com/en-us/library/bb546085(v=vs.110).aspx

2 solutions

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

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

Sergey Alexandrovich Kryukov · Answer 1 · 2015-04-11T15:12:00

You are badly misusing the event wait handle objects. These events are used only to notify the thread in a wait state, to wake it up. Actually, this is not an "event" in the sense of something you can "send" and "receive", this is a way to throttle execution of some thread without any waste of CPU time (as it happens with spin wait): the thread waiting for the event wait handler object is switched out and is not scheduled back to execution until it is waken up by the event wait handler set by another thread. It also can be used for thread synchronization, to make one thread waiting for another thread to complete some part of work. As all blocking call, it should be used with great consideration and theoretical calculations of the application lifetime.

Also, manual reset right after waking up (or almost, as in your case) can be considered as another abuse. (But it depends on what you try to achieve.) You could use System.Threading.AutoResetEvent. The functionality is no the same as in your seemingly "simulated" auto reset. It is impossible to guarantee simulation AutoResetEvent's reset with ManualResetEvent reset: auto resetting mechanism guarantees that exactly one thread at a time is passed through the point when the thread is waken up; the second thread will be always blocked again.

Your static class-factory methods are totally redundant: if you want to choose auto or manual reset depending on condition, you could use the base class System.Threading.EventWaitHandle and control the type of reset using its constructor, one of the constructors using EventResetMode argument: https://msdn.microsoft.com/en-us/library/system.threading.eventwaithandle%28v=vs.110%29.aspx.

Your RaiseEvent method is correct (however, it's not clear why writing a separate method, but it's OK), but you did not show where you called it. It will really wake up the thread blocked at the wait for the event wait handler. It all depends on when you call it. But main thing is: there is no such thing as "receive" this kind of event.

See also my past answers on this topic and on the purpose of these classes:
ManualResetEvent and AutoResetEvent in Thread,
pause running thread,
Making Code Thread Safe.,
Running exactly one job/thread/process in webservice that will never get terminated (asp.net)..

Now, these classes are mostly used for thread synchronization for the threads of the same process. For IPC, there are many different facilities. I would like to mention one which is often forgotten: sockets. Remember that, historically, sockets have been developed purely as IPC facility, only later used for networking. This is still a very good and flexible IPC tool. Please see:
https://msdn.microsoft.com/en-us/library/system.net.sockets%28v=vs.110%29.aspx.

—SA

CSharpNewbie 2 · Answer 2 · 2015-04-12T12:28:00

Here is the solution using the EventWaitHandle to achieve synchronization between multiple processes. I am posting it so that it could be helpful to somebody else.

Used the below two links to achieve the task of notifying client application from a windows service. After using the below, please make sure to use the 'Global\" prefix while creating the event as the Windows Services run in session 0, and user applications run in session 1 or higher. So for a service and a user application to communicate, they must use global objects.

http://blogs.msdn.com/b/mattdotson/archive/2006/03/03/543143.aspx[^]

https://msdn.microsoft.com/en-us/library/z4c9z2kt(v=vs.110).aspx[^]

Using Named events for inter process communication

2 solutions

Solution 1

Solution 4

Add your solution here

Preview 0