I'm not sure how clearly I've explained that - if you want I can throw together a little code example that shows the idea to help clarify. At this point, the other thread will get hold of the lock, and this will effectively suspend the main thread: when the main thread next tries to acquire the lock, it'll be made to sit and wait until this other thread releases the lock. It will probably have to wait for a bit - it won't be able to acquire the lock until the main thread gets to the point where it release the lock for a while. If you then want to stop the main thread for a bit, some other thread simply has to try and acquire this lock. You could modify that loop so that each time it starts doing some work, it first acquires a lock and holds onto it for as long as it's doing the current piece of work, and then have it release the lock before waiting for the next work item. What is your main thread doing? Is there some main loop that it sits in processing stuff? If so, that's probably the key to solving this. And once you've written one of those, it provides a solution to your problem and you don't really need SynchronizationContext any more.
#Suspend itimer while in handler c windows#
And you'd also need to provide some kind of mechanism in your main thread that performed a similar role to the message pump in a windows app: some sort of loop that waits for messages or input from a variery of sources. It is technically possible to use SynchronizationContext, but you'd need to do most of the implementation work yourself. So there isn't even a reliable way to say what is the 'main thread' in a console app: there might not actually be one main thread!) You can have several threads all writing directly to the console, and as long as they all take it in turns, it's allowed. (In fact there isn't even a standard way of determining which thread 'owns' the console. So there's no standard way of getting a message to the main thread. Unfortunately, there isn't any equivalent to the message pump in a console app. In WPF it's done through the WPF dispatcher mechanism.
In Windows Forms, this is done by posting messages to a window. The whole SynchronizationContext mechanism relies on there being some way to send messages to the target thread. It can also simplify things - if all your interesting code runs on the same thread, you don't need to worry about synchronization. It just sits and waits until the main thread is good and ready, and once it is, gets that thread to do the work. This is safer than trying to suspend the main thread. This will have the effect you require: the main thread won't be able to do anything else because it'll be busy running that bit of code! This uses the SynchronizationContext to run that innermost piece of code on the UI thread. Then, when an event handler is called on a non-main thread, do something like this:ĭebug.WriteLine( "I'm on the main thread! " + Public static SynchronizationContext MainContext MainContext = SynchronizationContext.Current Protected override void OnLoad( EventArgs e) You could do something like this in a Form: If it's either Windows Forms or WPF, you can use the SynchronizationContext class. There's no guarantee that there will be a "Main Thread" in general!) (The reason for that is that there is no one good definition of "Main Thread" - that means different things to different frameworks. What kind of application is this? Is it Windows Forms? WPF? Console? This matters because it makes a difference to the answer. In general, event sources raise events on whatever thread they want to raise them on. For example, a Windows Forms control always raises events on the UI thread. What ' nobugz' says is not true in general.
0 kommentar(er)
