I have my main GUI thread, and a second thread running inside it\'s own ApplicationContext (to keep it alive, even when there is no work to be done). I want to call a method
Wow, I can't believe how may people didn't bother reading the question.
Anyways, this is what I do.
Make sure that you don't share objects between the two threads. Once your GUI thread sticks a message in the Queue, the GUI thread no longer owns the message. It cannot hold a reference to the message, or you will get yourself into trouble.
This won't give you the best possible performance, but it will be good enough for most applications. And more importantly, it will make it much harder to make a mistake.
UPDATE: Don't use a SyncLock and Queue. Instead use a ConcurrentQueue, which will handle any locking automatically for you. You'll get better performance and are less likely to make a mistake.
Dude, read Albahari's .Net threading free ebook. I'm connected to it by any means, so this is no plug. I've read it, had my coworkers read it, and i've used it many times.
I would recommend creating a producer/consumer class, where you can start a single thread that waits (non blocking), enqueue tasks to its queue, and signal it to start working.
just google for it.
You can use events or as Grauenwolf said - a message cue. I wrap each of my thread as a management singleton, from there you can implement either easily. You could even do poor man public properties to flip bits.
Also you could implement a state machine, and instead of pass messages each thread could monitor each other