views:

78

answers:

4

Is there any way to get a delegate to run on a specific thread?

Say I have:

CustomDelegate del = someObject.someFunction;
Thread dedicatedThread = ThreadList[x];

Can I have a consistent background long running thread and invoke my own delegates on it whenever I need it. It has to be the same thread each time.

[Edit]

The reason why I want it to be on a dedicated thread is time is that I inten to run the delegate on it and suspend the thread after y milliseconds, and resume the thread when I run another delegate on it. I see this isn't possible. I will have a delegate queue and let the main function of the thread read and run from it.

To clarify with a concrete example, I have a game system with a bunch of player threads. I would like each playerthread to run event handlers for game events on it. If the event handlers take too much time I would like to be able to pause that particular player until the next event by suspending its thread.

Thus having a dedicated thread on which I can run multiple event handlers I can pause a particular player's AI in case it became bugged or is taking too long.

+1  A: 

Normally, I would suggest just using a the thread pool or BackgroundWorker class - but these do not guarantee that work will occur on any particular thread. It's unclear why you care which thread runs the works, but assuming that it does somehow matter ...

You would have to pass the Delegate object through some kind of shared memory, like a queue. The background thread would have to watch this queue, pull delegates off of it when they exist, and execute them.

If it turns out that the thread pool is acceptable to run your code, you could always use the BeginInvoke method of the delegate to do so:

// wrap your custom delegate in an action for simplicity ...
Action someCode = () => yourCustomDelegate( p1, p2, p3, ... );
// asynchronously execute the currying Action delegate on the threadpool...
someCode.BeginInvoke( someCode.EndInvoke, action );
LBushkin
+1  A: 

Unfortunately there really is nothing built in to do this on any generic thread. You can accomplish this by creating a class that wraps a Thread and implements ISynchonizeInvoke.

A simple approach is to create an event processing queue on the dedicated thread as LBushkin mentions. I suggest using a Queue<Action> class and calling the Action delegate directly. You can accomplish most tasks that you would need using anonymous delegate actions.

Finally, just as a word of warning, I would suggest you use a Semaphore or EventWaitHandle instead of Thread.Sleep on your dedicated thread. It is definitely more friendly than executing your background loop over and over again when its unnecessary.

Justin Breitfeller
Thank you, I was intending to run the background loop over and over. I will look into an event wait handler
Raynos
I agree with the warning about `Thread.Sleep`; however, the op should implement `SynchronizationContext` rather than the outdated `ISynchronizeInvoke`.
Stephen Cleary
A: 

For threads that you create, you can only specify the ThreadStart delegate when you create them. There's no provision for injecting a different delegate into a created thread. The Thread Pool is different in that it allows you to submit delegates to previously created threads that it starts on your behalf.

It's not clear what problem you're trying to solve. What are you trying to accomplish (or avoid) by trying to run multiple delegates on one thread?

ebpower
+1  A: 

I think the best solution is to use Task objects and queue them to an StaThreadScheduler running a single thread.

Alternatively, you could use the ActionThread in Nito.Async to create a normal thread with a built-in queue of Action delegates.

However, neither of these will directly address another need: the ability to "pause" one action and continue with another one. To do this, you'd need to sprinkle "synchronization points" throughout every action and have a way to save its state, re-queue it, and continue with the next action.

All that complexity is very nearly approaching a thread scheduling system, so I recommend taking a step back and doing more of a re-design. You could allow each action to be queued to the ThreadPool (I recommend just having each one be a Task object). You'll still need to sprinkle "synchronization points", but instead of saving state and re-queueing them, you'll just need to pause (block) them.

Stephen Cleary
Thank you for pointing out the ActionThread, that looks very useful. I needed to encapsulate external code over which I have little control in a thread. All I have is delegates to the external code. If I can insure that the object is in one particular thread I can "pause" that object by just suspending the thread. I don't think the threadpool will allow me to "pause" the object nicely.
Raynos
A word of warning: it is possible (even likely) to cause deadlocks accidentally by suspending/resuming threads. If at all possible, change the external code. If that isn't possible, then consider using thread priorities instead of suspend/resume.
Stephen Cleary