How can I notify the main thread of some message on another thread without blocking and waiting?

I'm writing a c# component that will only be used internally at my company. The component encapsulates communication with a number of servers that particular desktop applications need to communicate with. The servers can send unsolicited messages to the component, which are 'caught' in a separate thread.

I want the majority of this component to execute under the context of its creating thread. I do not wish the separate message thread to do any message processing. Instead, I would like to notify the main thread that there is a message awaiting processing. The reason for wanting to execute under the context of the creating thread, is that开发者_开发问答 users of the library may not know multi-threading, and I'd like to be able to synchronize all operations if possible.

Is there an easy way of signaling a running thread? The main thread will be doing all kinds of constant processing, and the message thread will be constantly spinning waiting for messages. It may be worth noting that the message thread is encapsulated in a third party library. Once it receives a message, it executes a callback. I'd like the callback to do something like mainthread.notify(message).

Edit: Sorry I wasn't too clear on what I want the main thread to do. I don't want the main thread to immediately process the message sent by the message thread. I want it to process the message at some time in the near future (like how the WinForms Message Loop works).

Edit 2:

The scenario:

Console App created on Thread1  
Thread2 created, which spins listening for Messages
Console App runs as normal
Message arrives on Thread2
Thread2 fires event MessageReady(sender, message)
Thread2 continues spinning
At the earliest convenience, Thread1 processes the message from MessageReady

I've done some reading, and it appears that marshaling code to another thread is quite a difficult manner, and I'm doubting that synchronizing this process would be worth the effort.

No, that's not possible. A thread has to go idle before you can inject code into it. That's done by, for example, Control.BeginInvoke (Windows Forms) or Dispatcher.BeginInvoke (WPF). These UI libraries often require code to be executed on the UI thread so they have explicit support for marshaling calls to the UI thread.

It is important for a thread to be in an "idle" state. You would have horrible re-entrancy problems if .NET supported some kind of asynchronous injection method.

If your component will be on a windows form, then here is one route to accomplishing your goal:

In your component code:

public event EventHandler MessageReceived;

private void UnsolicitedMessageReceived(...)
{
  if (MessageReceived != null)
  {
   // this will invoke on UI thread
   Parent.Invoke(MessageReceived, this, EventArgs.Empty);
  }
}

In your form you might have:

MyCoolComponent1.MessageReceived += new EventHandler(MessageReceived);

private void MessageReceived(object sender, EventArgs e)
{
  // do some stuff here
}

Since you probably don't want the thread to just drop what they're currently doing, you'll need some sort of task queue for the thread to look at - this doesn't have to be any more advanced than a Queue, where T is some type you use to represent each task. Maintain a queue and add the messages there, so the threads can then process them whenever they're done with what they're currently doing.

Use a semaphore to let your worker thread wait for new data if the queue is empty, and pulse on that semaphore if you add a new message to an empty queue. That prevents them from wasting CPU cycles on constantly polling the queue.

If you want several worker threads, all you need to do is make sure each thread has its own queue, and you'll be in full control over which thread runs what.

EDIT: On reading the question again, I'm not sure if your problem is that you really need the thread to do some work immediately. If that's the case, I can't see this being possible, since you can't just inject code at a random time - you'd most likely break whatever was executing at that point.

One option is to pass a delegate from your main thread to the child threads that they can use as a callback to signal that they have a message. The child threads can pass the message through the callback, which saves the message in a memory-based collection or to persistent storage, and the main thread checks this when appropriate.

You could take this one step further and not have the child threads signal the main thread at all, but instead have the child threads write the messages to a database, and have the main thread check the database when it's convenient. You can even use the database (through transactions) to handle concurrency. And this gives the advantage of not losing messages if the system crashes. Even lets you spread child threads (or main threads) across servers.