CODEWITHSUNDEEP
c#multithreading
Michael Bedford
Michael Bedford

Reputation: 1814

Event handler timing and threading

I am still learning C# so please be easy on me. I am thinking about my application I am working on and I can't seem to figure out the best approach. This is not a forms application but rather a console. I am listening to a UDP port. I get UDP messages as fast as 10 times per second. I then look for a trigger in the UDP message. I am using an event handler that is raised each time i get a new UDP packet which will then call methods to parse the packet and look for my trigger. So, i have these questions.

  1. With regard to threading, I assume a thread like my thread that listens to the UDP data should be a permanent thread?
  2. Also on threading, when I get my trigger and decide to do something, in this case send a message out, i gather that I should use a thread pool each time I want to perform this task?
  3. On thread pools, I am reading that they are not very high priority, is that true? If the message I need to send out is critical, can i rely on thread pools?
  4. With the event handler which is raised when i get a UDP packet and then calls methods, what is the best way to ensure my methods all complete before the next packet/event is raised? At times I see event queue problems because if any of the methods take a bit longer than they should (for exampe writing to a DB) and the next packet comes in 100ms later, you get event queue growth because you cannot consume events in a timely manner. Is there a good way to address this?

Upvotes: 0

Views: 209

Answers (2)

barakcaf
barakcaf

Reputation: 1324

I'll adress your points:

  1. your listeting thread must be a 'permanent' thread that gets messages and distribute them.

  2. (2+3) - Look at the TPL libarary you should use it instead of working with threads and thread pools (unless you need some fine control over the operations which, from your question, seems like you dont need) - as MSDN states:

    The Task Parallel Library (TPL) is based on the concept of a task, which represents an asynchronous operation. In some ways, a task resembles a thread or ThreadPool work item, but at a higher level of abstraction

  3. Look into using MessageQueues since what you need is a place to receive messages, store them for some time (in memory in your case)and handle them at your own pace.

    You could implement this yourself but you'll find it gets complicated quickly,

    I recommend looking into NetMQ - it's easy to use, especially for what you describe, and it's in c#.

Upvotes: 1

Ondrej Janacek
Ondrej Janacek

Reputation: 12616

With regard to threading, I assume a thread like my thread that listens to the UDP data should be a permanent thread?

There are no permanent threads. However there should be a thread that is responsible for receiving. Once you start it, let it run until you no longer need to receive any messages.

Also on threading, when I get my trigger and decide to do something, in this case send a message out, i gather that I should use a thread pool each time I want to perform this task?

That depends on how often would you send out messages. If your situation is more like consumer/producer than a separate thread for sending is a good idea. But if you send out a message only rarely, you can use thread pool. I can't define how often rare means in this case, you should watch your app and decide.

On thread pools, I am reading that they are not very high priority, is that true? If the message I need to send out is critical, can i rely on thread pools?

You can, it's more like your message will be delayed because of slow message processing or slow network rather than the thread pool.

With the event handler which is raised when i get a UDP packet and then calls methods, what is the best way to ensure my methods all complete before the next packet/event is raised? At times I see event queue problems because if any of the methods take a bit longer than they should (for exampe writing to a DB) and the next packet comes in 100ms later, you get event queue growth because you cannot consume events in a timely manner. Is there a good way to address this?

Queue is a perfect solution. You can have more queues if some messages are independent of others and their execution won't collide and then execute them in parallel.

Upvotes: 2

Related Questions