C＃在添加的线程中触发事件

Question

Consider two classes; Producer and Consumer (the same as classical pattern, each with their own threads). Is it possible for Producer to have an Event which Consumer can register to and when the producer triggers the event, the consumer's event handler is run in its own thread? Here are my assumptions:

• Consumer does not know if the Producer 's event is triggered within his own thread or another.

• Neither Producer nor Consumer are descendants of Control so they don't have BeginInvoke method inherited.

PS. I'm not trying to implement Producer - Consumer pattern. These are two simple classes which I'm trying to refactor the producer so it incorporates threads.

[UPDATE]

To further expand my problem, I'm trying to wrap a hardware driver to be worked with in the simplest way possible. For instance my wrapper will have a StateChanged event which the main application will register to so it will be notified when hardware is disconnected. As the actual driver has no means other than polling to check its presence , I will need to start a thread to check it periodically. Once it is not available anymore I will trigger the event which needs to be executed in the same thread as it was added. I know this is a classical Producer-Consumer pattern but since I'm trying to simplify using my driver-wrapper, I don't want the user code to implement consumer.

[UPDATE]

Due to some comments suggesting that there's no solution to this problem, I would like to add few lines which might change their minds. Considering the BeginInvoke can do what I want, so it shouldn't be impossible (at least in theory). Implementing my own BeginInvoke and calling it within the Producer is one way to look at it. It's just that I don't know how BeginInvoke does it!

Answer 1

You want to do inter thread communication. Yes it is possible. Use System.Windows.Threading.Dispatcher http://msdn.microsoft.com/en-us/library/system.windows.threading.dispatcher.aspx

The Dispatcher maintains a prioritized queue of work items for a specific thread. When a Dispatcher is created on a thread, it becomes the only Dispatcher that can be associated with the thread, even if the Dispatcher is shut down. If you attempt to get the CurrentDispatcher for the current thread and a Dispatcher is not associated with the thread, a Dispatcher will be created. A Dispatcher is also created when you create a DispatcherObject. If you create a Dispatcher on a background thread, be sure to shut down the dispatcher before exiting the thread.

Answer 2

Yes there is a way to do this. It relies on using the SynchronizationContext class ( docs ). The sync context abstracts the operations of sending messages from one thread to another via the methods Send (synchronous for the calling thread) and Post (async for the calling thread).

Let's take a slightly simpler situation where you only want the capture one sync context, the context of the "creator" thread. You would do something like this:

using System.Threading;

class HardwareEvents
{
    private SynchronizationContext context;
    private Timer timer;

    public HardwareEvents() 
    {
       context = SynchronizationContext.Current ?? new SynchronizationContext();
       timer = new Timer(TimerMethod, null, 0, 1000); // start immediately, 1 sec interval.
    }

     private void TimerMethod(object state)
     {
         bool hardwareStateChanged = GetHardwareState();
         if (hardwareStateChanged)
             context.Post(s => StateChanged(this, EventArgs.Empty), null); 
     }

     public event EventHandler StateChanged;

     private bool GetHardwareState()
     {
        // do something to get the state here.
        return true;
     }
}

Now, the creating thread's sync context will be used when events are invoked. If the creating thread was a UI thread it will have a sync context supplied by the framework. If there is no sync context, then the default implementation is used, which invokes on the thread pool. SynchronizationContext is a class that you can subclass if you want to provide a custom way to send a message from the producer to the consumer thread. Just override Post and Send to send said message.

If you wanted every event subscriber to get called back on their own thread, you would have to capture the sync context in the add method. You then hold on to pairs of sync contexts and delegates. Then when raising the event, you would loop through the sync context / delegate pairs and Post each one in turn.

There are several other ways you could improve this. For example, you may want to suspend polling the hardware if there no subscribers to the event. Or you might want to back off your polling frequency if the hardware does not respond.

Answer 3

First, please note that in .NET / the Base Class Library, it is usually the event subscriber's obligation to ensure that its callback code is executing on the correct thread. That makes it easy for the event producer: it may just trigger its event without having to care about any thread affinities of its various subscribers.

Here's a complete example step-by-step of a possible implementation.

Let's start with something simple: The Producer class and its event, Event . My example won't include how and when this event gets triggered:

class Producer
{
    public event EventHandler Event;  // raised e.g. with `Event(this, EventArgs.Empty);`
}

Next, we want to be able to subscribe our Consumer instances to this event and be called back on a specific thread (I'll call this kind of thread a "worker thread"):

class Consumer
{
    public void SubscribeToEventOf(Producer producer, WorkerThread targetWorkerThread) {…}
}

How do we implement this?

First, we need the means to "send" code to a specific worker thread. Since there is no way to force a thread to execute a particular method whenever you want it to, you must arrange for a worker thread to explicitly wait for work items. One way to do this is via a work item queue. Here's a possible implementation for WorkerThread :

sealed class WorkerThread
{
    public WorkerThread()
    {
        this.workItems = new Queue<Action>();
        this.workItemAvailable = new AutoResetEvent(initialState: false);
        new Thread(ProcessWorkItems) { IsBackground = true }.Start();
    }

    readonly Queue<Action> workItems;
    readonly AutoResetEvent workItemAvailable;

    public void QueueWorkItem(Action workItem)
    {
        lock (workItems)  // this is not extensively tested btw.
        {
            workItems.Enqueue(workItem);
        }
        workItemAvailable.Set();
    }

    void ProcessWorkItems()
    {
        for (;;)
        {
            workItemAvailable.WaitOne();
            Action workItem;
            lock (workItems)  // dito, not extensively tested.
            {
                workItem = workItems.Dequeue();
                if (workItems.Count > 0) workItemAvailable.Set();
            }
            workItem.Invoke();
        }
    }
}

This class basically starts a thread, and puts it in an infinite loop that falls asleep ( WaitOne ) until an item arrives in its queue ( workItems ). Once that happens, the item — an Action — is dequeued and invoked. Then the thread goes to sleep again ( WaitOne )) until another item is available in the queue.

Action s are put in the queue via the QueueWorkItem method. So essentially we can now send code to be executed to a specific WorkerThread instance by calling that method. We're now ready to implement Customer.SubscribeToEventOf :

class Consumer
{
    public void SubscribeToEventOf(Producer producer, WorkerThread targetWorkerThread)
    {
        producer.Event += delegate(object sender, EventArgs e)
        {
            targetWorkerThread.QueueWorkItem(() => OnEvent(sender, e));
        };
    }

    protected virtual void OnEvent(object sender, EventArgs e)
    {
        // this code is executed on the worker thread(s) passed to `Subscribe…`. 
    }
}

Voilà!

---

PS (not discussed in detail): As an add-on, you could package the method of sending code to WorkerThread using a standard .NET mechanism called a SynchronizationContext :

 sealed class WorkerThreadSynchronizationContext : SynchronizationContext { public WorkerThreadSynchronizationContext(WorkerThread workerThread) { this.workerThread = workerThread; } private readonly WorkerThread workerThread; public override void Post(SendOrPostCallback d, object state) { workerThread.QueueWorkItem(() => d(state)); } // other overrides for `Send` etc. omitted } 

And at the beginning of WorkerThread.ProcessWorkItems , you'd set the synchronization context for that particular thread as follows:

 SynchronizationContext.SetSynchronizationContext( new WorkerThreadSynchronizationContext(this)); 

Answer 4

I posted earlier that I've been there, and that there is no nice solution.

However, I just stumbled upon something I have done in another context before: you could instantiate a timer (that is, Windows.Forms.Timer ) when you create your wrapper object. This timer will post all Tick events to the ui thread.

Now if you're device polling logic is non-blocking and fast, you could implement it directly inside the timer Tick event, and raise your custom event there.

Otherwise, you could continue to do the polling logic inside a thread, and instead of firing the event inside the thread, you just flip some boolean variable which gets read by the timer every 10 ms, who then fires the event.

Note that this solution still requires that the object is created from the GUI thread, but at least the user of the object will not have to worry about Invoke .

Answer 5

It is possible. One typical approach is to use the BlockingCollection class. This data structure works like a normal queue except that the dequeue operation blocks the calling thread if the queue is empty. The produce will queue items by calling Add and the consumer will dequeue them by calling Take . The consumer typically runs it's own dedicated thread spinning an infinite loop waiting for items to appear in the queue. This is, more or less, how the message loop on the UI thread operates and is the basis for getting the Invoke and BeginInvoke operations to accomplish the marshaling behavior.

public class Consumer
{
  private BlockingCollection<Action> queue = new BlockingCollection<Action>();

  public Consumer()
  {
    var thread = new Thread(
      () =>
      {
        while (true)
        {
          Action method = queue.Take();
          method();
        }
      });
    thread.Start();
  }

  public void BeginInvoke(Action method)
  {
    queue.Add(item);
  }
}