Lots of messages to be parsed in lots of threads?

I do recieve lots of messages (4K+ every 4 seconds), my software needs to parse each ofv those in order to do updates on my objects.
I want this parsing to be done in a seperate thread, however to start of a new thread for each message produces to much threads.

Is there a way to have a thread wait for events/calls/etc?

Have you considered the Task Parallelism (Task Parallel Library).

Which version of the framework. I totally agree with ident, but you have to be targeting 4.0 at a minimum and 4.5 adds some nice features.

TPL, to my understanding, does not solve my problem.
Presently my UDP-Listener raises an event on the GUI, the GUI holds the "Parse_Message" Sub.
That is conviniet since the GUI-Thread is "alive", however I'd like to raise an event and have a seperate thread react on that. But how can I start a thread that just waits for specific events?

[edit] Framework 4.0

4.5 wow. Just jumped from xp to 8.1 and currently learning some of the new classes. Really impressive stuff.

Quote:

---

Originally Posted by opus

TPL, to my understanding, does not solve my problem.
Presently my UDP-Listener raises an event on the GUI, the GUI holds the "Parse_Message" Sub.
That is conviniet since the GUI-Thread is "alive", however I'd like to raise an event and have a seperate thread react on that. But how can I start a thread that just waits for specific events?

---

By passing an instance of the object of said class to this thread and loop/wait and handle according when the even is raised. I think JMC has an example in the code bank waiting(pausing)

Thanks for the input, but you lost me somewhere in the middle.

Quote:

---

Originally Posted by ident

By passing an instance of the object of said class to this thread and loop/wait and handle according when the even is raised. I think JMC has an example in the code bank waiting(pausing)

---

"By passing an instance of the object of said class " Which class are you referring to? (The UDP-listener, the GUI[not really],????)

I would probably go for an initial approach of putting the messages to be parsed into a ConcurrentQueue, and then signalling a wait handle.

Start off a single thread that loops initially waiting for the waithandle to be signalled, once it is it clears the wait handle and tries to dequeue an item from the queue and process it. It keeps dequeuing until there are no messages in the queue to be dequeued, at which point it goes back to the beginning of the loop and waits for the handle to be signalled again.

This is a well established pattern that is robust against all the usual threading trickiness.

You can't have a background thread waiting for events without some kind of message pump on that thread, which the above pattern is an example of. The GUI thread could be reacting to the events from the udp listener and pushing the messages onto the queue.

Thanks Evil_Giraffe, I was coming to nearly the same solution.
I did digg into TPL, especially Producer/Consumer Patterns
My actual approach goes like:
UDP-Listener Raises an Event MessageIn (with the message in the Custom-eventargs)

GUI reacts on this event by putting the recieved message in a BlockingCollection (which would be the producer)

The Consumer is started by the GUI just after creating the UDP-Listener as a seperate Thread, it looks like this:

Code:

---

Private Sub MessageConsumer()
  Dim MessageIn as Byte()
  Do
      MessageIn=BlockingMessageCollection.Take
      Parse_Message(MessageIn)
  Loop
End Sub

---

At the first look it does what I was looking for.