4

I'm working on a program which reacts to events coming from an internet socket, and possibly from timers as well. It seems natural to use two threads:

  • One for the main program
  • A second one which listens to the socket, parses the input, and raises an appropriate event.

Additional requirements:

  1. The application should not rely on a UI thread (it may be run as a console application).
  2. The main program should process messages synchronously, i.e. in the order in which they arrived.
  3. The main thread must not block on waiting for timers (I guess this means I have to run timers on different threads).

And now for some questions :-):

  1. I'm guessing requirement #1 means that I don't have a built-in message pump, so I can't use Invoke() from the socket listener / timer threads. Is this correct?
  2. How can I safely raise events on one thread (e.g. the listener), and have the subscribers run synchronously on another (the main thread)?
  3. It is very likely that new events will be raised before the subsequent handler is done. What will happen in this case? Will the event be buffed somewhere by the CLR, or will it be ignored?

And last but not least: I guess I'm aiming for the parallel for the message Producer/Consumer paradigm, but instead of messages, I want to use events. Do you think there is a better approach?

Thanks,

Boaz

EDIT

I want to explain my motivation for using events in the first place. The application is an automated trading engine which has to respond to events that happen in the market (e.g. a change in the price of a stock). When this happens, there may be multiple subscribers on the main thread which should be invoked, which is a classical scenario to use events.

I guess I can always use the Producer/Consumer with some message queue, and have the consumer raise events on the main thread, but I figured there might be a more direct way.

bavaza
  • 10,319
  • 10
  • 64
  • 103
  • What is the main driver for the use of events? A producer/consumer seems appropriate in this case, it is well known and fairly easy to implement. Thread-safe event handling can be (surprisingly) tricky. – Jakob Möllås May 17 '11 at 07:16

2 Answers2

4

I think using messages will be the simplest way. If you are using C# 4 this is very easy thanks to the BlockingCollection<>

So have a shared BlockingCollection, where Message is your message class.

Then in your worker thread you do this

var msgEnum = blockingCollection.GetConsumingEnumerable();

//Per thread
foreach( Message message in msgEnum )
{
   //Process messages here
}

That is it.

The GetConsumingEnumerable() will block until there is a message to process. It will then remove the message from the queue and your loop will process it.

What is nice about this is that you can add more threads and in each one you just have the foreach loop.

When you are done call blockingCollection.CompletedAdding();

BTW the queue handles concurrency and will queue messages sent at the same time etc.

Hope this helps

Andre

Andre
  • 4,560
  • 2
  • 21
  • 27
  • Yeah, that is an interesting pattern! Tnx! – Jakob Möllås May 17 '11 at 07:34
  • rumor has it that there is a significant performance penalty when using `BlockingCollection` as compared with just using `lock()` on a standard queue. Moreover, you can't have the posting thread spin lock. Is this actually so? – bavaza May 18 '11 at 06:18
  • @bavaza I've not seen anything suggesting this. Do you have any links? Having said that, even if there is a big issue (which I doubt) it more than likely wont affect many people. i.e. don't optimize prematurely. The simplicity of a solution build around a blocking collection is hard to beat. Replacing the example above with a thread safe alternative using locks (correctly) would not be nearly as pretty or easy to understand. You could also go with a full blown messaging system (Active MQ, Rabbit MQ, even Zero MQ etc) but that would raise the complexity... – Andre May 21 '11 at 14:07
  • see e.g. [here](http://stackoverflow.com/questions/3039724/blockingcollectiont-performance) about performance. I totally accept your views about simplicity and readability. I guess I'll have to wait until the benchmarking. – bavaza May 23 '11 at 07:03
2

You could implement a shared queue between your threads. Whenever an event is raised you could push it in the queue. The main thread is an endless loop that checks for new events, removes them from the queue, handles the event and when there are no more events it sleeps for some time.

Blackcom
  • 146
  • 6