One easy approach is actually to take your idea one step futher – instead of making a TaskScheduler and passing it around, you can create a TaskFactory and pass it around:

TaskFactory uiFactory = new TaskFactory(TaskScheduler.FromCurrentSynchronizationContext());

Then, in your background thread, updating a UI item becomes:

string newText = ComputeText(); // Running in background thread/task
uiFactory.StartNew(() => this.textBox1.Text = newText);

It’s the same idea, but a bit less typing…

-Reed

Thanks for this posting. I needed an easy way to update the user thread in a GUI application when the task finished and this works like a treat. What I did need to do however is change the declaration of the context to

TaskScheduler context = TaskScheduler.FromCurrentSynchronizationContext();

and then pass the context to the task itself as a parameter.

If there is a simple way to update a control on the GUI thread without stopping the GUI thread then I would appreciate an uncomplicated example (like in updating a marqueeControl). I must be missing something because with the ‘old’ background threading scenario you just created an event.

This is required only because there is no overload for TaskFactory.StartNew that takes a TaskScheduler but not the token and creation options. The only other option is to create the task, then use Task.Start(scheduler). Otherwise, you need to specify the other items, as the Task API just exposes it that way.

-Reed

when starting a Task directly on the UI thread why the need for the cancellation token and TaskCreationOptions?

thanks
Paul

A much easier way of approaching threading.

That’s actually not accurate. The default TaskScheduler, which is what is used when you do Task.Factory.StartNew, will use always use a ThreadPool thread to execute your Task, unless the LongRunning hint is specified, in which case it will use a dedicated thread (in .NET 4′s implementation). Either way, it should NEVER run on the UI thread, since the UI thread should never be on a ThreadPool thread.

Tasks will only get scheduled on the current thread when the current thread is a threadpool thread, or the current thread is blocking on the result of a collection of Tasks (including the one that needs to execute).

That being said, if you want to force a task to run on a dedicated thread, you can do so by specifying the LongRunning hint (in the current implementation). This is a much simpler alternative to creating a custom TaskScheduler. Using an STA thread scheduler is really overkill, unless you specifically need an STA thread.

-Reed

You can reed about it here: http://tillias.wordpress.com/2010/07/05/net-4-system-threading-tasks-and-wpf-ui-thread/