Develop Reference

Why does user interface still freeze?

I'm trying to prevent freezing application interface at waiting moment, so I code this function, but it doesn't work.
Where is the mistake, and how can I solve this?
async void buttonBlocking()
{
await Task.Run(() =>
{
if (irTryCounter % 3 == 0)
{
this.Dispatcher.Invoke(() =>
{
grdLogin.IsEnabled = false;
Thread.Sleep(10000);
grdLogin.IsEnabled = true;
});
}
});
}

If your buttonBlocking is invoked from UI thread, then you can simplify your code:
async void buttonBlocking()
{
if (irTryCounter % 3 == 0)
{
grdLogin.IsEnabled = false;
await Task.Delay(10000);
grdLogin.IsEnabled = true;
}
}
This way it won't block your UI

The mistake, as pointed by Matthew Watson in a comment, is that the Dispatcher.Invoke() will run the code on the UI thread, so the Thread.Sleep will be blocking the UI thread.
Now let's see how this problem can be fixed. I am assuming that your code is an event handler, and you want this handler to run asynchronously. This is the only valid scenario for using an async void method. In any other case you should use async Task.
private async void Button1_Click(object sender, RoutedEventArgs e)
{
if (irTryCounter % 3 == 0)
{
grdLogin.IsEnabled = false;
await Task.Run(() =>
{
// Here you can run any code that takes a long time to complete
// Any interaction with UI controls is forbidden here
// This code will run on the thread-pool, not on the UI thread
Thread.Sleep(10000);
});
grdLogin.IsEnabled = true;
}
}
In case the long-running operation returns a result that needs to be passed to the UI thread, use the Task.Run overload that returns a Task<TResult>:
int result = await Task.Run(() =>
{
Thread.Sleep(10000);
return 13;
});
// We are back on the UI thread, and the result is available for presentation
I am assuming that the Thread.Sleep(10000) is a placeholder for an actual synchronous operation that takes a long time to complete. It would be even better if this operation can be performed asynchronously, because it would not require consuming a ThreadPool thread for the whole duration of the operation. As an example, a delay can be performed asynchronously by using the Task.Delay method:
await Task.Run(async () =>
{
await Task.Delay(10000);
});
In this case the Task.Run wrapper may seem redundant, but actually it's not. Wrapping your asynchronous code in a Task.Run protects your application from badly behaving asynchronous APIs that block the current thread. The overhead of including the wrapper is minuscule, and should have no noticeable effect in a WinForms/WPF application. The exception is ASP.NET applications, where Task.Runing is inadvisable.

C# Many longrunning tasks in parallel

I would like to scrape data from one site, so because rapidity is important for my project i must run tasks in parallel. I have a method like this:
public void UpdateData(List<string> myList)
{
while(true)
{
...
...
}
}
And i would like to call the method with different arguments from buttonClick Event so i used this code:
var uiContext = TaskScheduler.FromCurrentSynchronizationContext();
var task1 = Task.Factory.StartNew(() => UpdateData(myList1), CancellationToken.None, TaskCreationOptions.LongRunning, uiContext);
var task2 = Task.Factory.StartNew(() => UpdateData(myList2), CancellationToken.None, TaskCreationOptions.LongRunning, uiContext);
The result is after first calling of tasks only the first one continues to update the argument(myList1).
Where is the problem?

You're explicitly asking the Task Scheduler to run tasks on UI context. There is only one UI context, so only one thread will run at a time.
Perform your tasks on non-UI context
When you need the UI context, marshal the calls as needed

How to wait until method complete in C#?

I have this C# code, it works but it won't wait until the method completed
foreach (var listBoxItem in visualListBox1.Items)
{
lblCursor.Text = "Processing.. " + listBoxItem;
Thread t = new Thread(() => extract_group(listBoxItem.ToString()));
t.IsBackground = false;
t.Name = "Group Scrapper";
t.Start();
}
How to wait until extract_group method is done before moving to the next listBoxItem?
I used t.join() but it made the UI unresponsive.

Using async/await helps you to not block main thread.
public async Task ExtractGroupAsync()
{
... (logic of the method)
... (you should use async methods here as well with await before executing those methods)
}
You execute this "ExtractGroup" task like:
var example = await ExtractGroupAsync();

It makes GUI unresponsive, because you are on GUI thread. Run whole code, in separate thread.
Note: when you want to access GUI elements from another thread, you should use invoke, for example:
t.Invoke(() => t.Name = "Group Scrapper");

If you want to stick with Thread I recommend using a WaitHandle e.g. AsyncManualResetEvent Class. This approach allows to make a thread wait without blocking CPU (e.g. spinlock).
Your provided example would become:
private static AsyncManualResetEvent mre = new AsyncManualResetEvent(false, true);
public async Task DoSomethingAsync(...)
{
foreach (var listBoxItem in visualListBox1.Items)
{
lblCursor.Text = "Processing.. " + listBoxItem;
Thread t = new Thread(() => ExtractGroup(listBoxItem.ToString()));
t.IsBackground = false;
t.Name = "Group Scrapper";
t.Start();
// Wait for signal to proceed without blocking resources
await mre.WaitAsync();
}
}
private void ExtractGroup(string groupName)
{
// Do something ...
// Signal handle to release all waiting threads (makes them continue).
// Subsequent calls to Set() or WaitOne() won't show effects until Rest() was called
mre.Set();
// Reset handle to make future call of WaitOne() wait again.
mre.Reset();
}
Another solution would be to go with the TPL and use Task instead of Thread:
public async Task DoWorkAsync()
{
foreach (var listBoxItem in visualListBox1.Items)
{
lblCursor.Text = "Processing.. " + listBoxItem;
// Wait for signal to proceed without blocking resources
await Task.Run(() => ExtractGroup(listBoxItem.ToString()));
}
}
The issue with your code sample is, that you are currently on the main thread, the UI thread. Calling Thread.Join() does what you think it does: it blocks the waiting thread until the running thread completes. But as mentioned, the waiting thread is the UI thread, so the UI becomes unresponsive and can even deadlock in some scenario. When you use async/await your invocations become asynchronous and hence awaitable without blocking the UI thread.

Running method in the background and UI Thread WPF

I'm having troubles with the following example:
public void Method()
{
LongRunningMethod();
}
LongRunningMethod() takes around 5 seconds to invoke. I am invoking Method() from the UI thread, so it obviously should freeze the UI. The solution for that is to run Method() within a new Task so I am running it like this:
Task.Factory.StartNew(()=>{Method()})
It's still blocking the UI so I thought whether LongRunningMethod() is using the UI context probably. Then I tried another solution:
new Thread(()=>Method()).Start()
and it started working. How is that possible? I know that Task is not guaranteed to be run on a different thread but CLR should be smart enough to figure out that it's long running method.

You are scheduling work on the User Interface (UI) Thread cause you are using
TaskScheduler.FromCurrentSynchronizationContext()) in this code:
Task nextTask = task.ContinueWith(x =>
{
DoSomething();
}, CancellationToken.None, TaskContinuationOptions.OnlyOnRanToCompletion, TaskScheduler.FromCurrentSynchronizationContext());
task.Start();
}
And this is a reason why your UI is frozen. To prevent try to change TaskScheduler to Default:
Task task = Task.Run(() => {; });
Task nextTask = task.ContinueWith(x =>
{
//DoSomething();
}, CancellationToken.None, TaskContinuationOptions.OnlyOnRanToCompletion, TaskScheduler.Default);
Task.Factory.StartNew is dangerous cause it uses TaskScheduler.Current as opposed to TaskScheduler.Default. To prevent this use Task.Run which always points to TaskScheduler.Default. Task.Run is new in .NET 4.5, if you're in .NET 4.0 you can create your TaskFactory with default parameters.
As MSDN says:
TaskScheduler.FromCurrentSynchronizationContext()) means schedule
a task on the same thread that the user interface (UI) control was
created on.
Update:
What happens when you run method RunTask():
var task = new Task(action, cancellationTokenSource.Token);
create a "task". (task is not run. The "task" is just queed to the ThreadPool.)
Task nextTask = task.ContinueWith(x =>
{
DoSomething();
}, CancellationToken.None, TaskContinuationOptions.OnlyOnRanToCompletion, TaskScheduler.FromCurrentSynchronizationContext());
create a "nextTask" which will start performing AFTER "task" is completed and the "nextTask" will be performed on UI thread as you've set a feature
TaskScheduler.FromCurrentSynchronizationContext().
task.Start();
You run your "task". When the "task" is completed, then "nextTask" is run by method "task.ContinuuWith()" which will be performed on UI thread you wrote (TaskScheduler.FromCurrentSynchronizationContext()
So to sum up, the two your tasks are interconnected and continuation of task is performed on UI thread which is a reason to freeze your UI. To prevent this behavior use TaskScheduler.Default.

This is exactly how it looks like:
public void RunTask(Action action){
var task = new Task(action, cancellationTokenSource.Token);
Task nextTask = task.ContinueWith(x =>
{
DoSomething();
}, CancellationToken.None, TaskContinuationOptions.OnlyOnRanToCompletion, TaskScheduler.FromCurrentSynchronizationContext());
task.Start();
}
public void DoSomething()
{
if(condition) // condition is true in this case (it's recurency but not permanent)
RunTask(() => Method()); // method is being passed which blocks UI when invoked in RunTask method
}
public void Method()
{
LongRunningMethod();
}
This is the starting point invocation (UI Thread):
RunTask(()=>Action());

Only a guess: Thread.Start creates a foreground thread. Maybe the method switches to a known foreground-thread when it detects, that it is run from a background-thread.
Hope it helps somehow.

RunAsync - How do I await the completion of work on the UI thread?

When awaiting Dispatcher.RunAsync the continuation occurs when the work is scheduled, not when the work has completed. How can I await the work completing?
Edit
My original question assumed the premature continuation was caused by the design of the API, so here's the real question.
When awaiting Dispatcher.RunAsync using an asynchronous delegate, using await within the delegate's code, the continuation occurs when the await is encountered, not when the work has completed. How can I await the work completing?
Edit 2
One reason you may need to dispatch work that's already on the UI thread is to workaround subtle timing and layout issues. It's quite common for values of sizes and positions of elements in the visual tree to be in flux and scheduling work for a later iteration of the UI can help.

I found the following suggestion on a Microsoft github repository: How to await a UI task sent from a background thread.
Setup
Define this extension method for the CoreDispatcher:
using System;
using System.Threading.Tasks;
using Windows.UI.Core;
public static class DispatcherTaskExtensions
{
public static async Task<T> RunTaskAsync<T>(this CoreDispatcher dispatcher,
Func<Task<T>> func, CoreDispatcherPriority priority = CoreDispatcherPriority.Normal)
{
var taskCompletionSource = new TaskCompletionSource<T>();
await dispatcher.RunAsync(priority, async () =>
{
try
{
taskCompletionSource.SetResult(await func());
}
catch (Exception ex)
{
taskCompletionSource.SetException(ex);
}
});
return await taskCompletionSource.Task;
}
// There is no TaskCompletionSource<void> so we use a bool that we throw away.
public static async Task RunTaskAsync(this CoreDispatcher dispatcher,
Func<Task> func, CoreDispatcherPriority priority = CoreDispatcherPriority.Normal) =>
await RunTaskAsync(dispatcher, async () => { await func(); return false; }, priority);
}
Once you do that, all you need to do is use the new RunTaskAsync method to have your background task await on the UI work.
Usage example
Let's pretend that this is the method that needs to run in the UI thread. Pay attention to the debug statements, which will help follow the flow:
public static async Task<string> ShowMessageAsync()
{
// Set up a MessageDialog
var popup = new Windows.UI.Popups.MessageDialog("Question", "Please pick a button to continue");
popup.Commands.Add(new Windows.UI.Popups.UICommand("Button 1"));
popup.Commands.Add(new Windows.UI.Popups.UICommand("Button 2"));
popup.CancelCommandIndex = 0;
// About to show the dialog
Debug.WriteLine("Waiting for user choice...");
var command = await popup.ShowAsync();
// Dialog has been dismissed by the user
Debug.WriteLine("User has made a choice. Returning result.");
return command.Label;
}
To await that from your background thread, this is how you would use RunTaskAsync:
// Background thread calls this method
public async void Object_Callback()
{
Debug.WriteLine("Object_Callback() has been called.");
// Do the UI work, and await for it to complete before continuing execution
var buttonLabel = await Dispatcher.RunTaskAsync(ShowMessageAsync);
Debug.WriteLine($"Object_Callback() is running again. User clicked {buttonLabel}.");
}
The output then looks like this:
Object_Callback() has been called.
Waiting for user choice...
User has made a choice. Returning result.
Object_Callback() is running again. User clicked Button 1.

Your question is assuming that you want to schedule (and wait for) work on a UI thread from a background thread.
You'll usually find your code is much cleaner and easier to understand (and it will definitely be more portable) if you have the UI be the "master" and the background threads be the "slaves".
So, instead of having a background thread await some operation for the UI thread to do (using the awkward and unportable Dispatcher.RunAsync), you'll have the UI thread await some operation for the background thread to do (using the portable, made-for-async Task.Run).

You can wrap the call to RunAsync in your own asynchronous method that can be awaited and control the completion of the task and thus the continuation of awaiting callers yourself.
Since async-await is centred on the Task type, you must orchestrate the work using this type. However, usually a Task schedules itself to run on a threadpool thread and so it cannot be used to schedule UI work.
However, the TaskCompletionSource type was invented to act as a kind of puppeteer to an unscheduled Task. In other words, a TaskCompletionSource can create a dummy Task that is not scheduled to do anything, but via methods on the TaskCompletionSource can appear to be running and completing like a normal job.
See this example.
public Task PlayDemoAsync()
{
var completionSource = new TaskCompletionSource<bool>();
this.Dispatcher.RunAsync(Windows.UI.Core.CoreDispatcherPriority.Normal, async () =>
{
try
{
foreach (var ppc in this.Plots.Select(p => this.TransformPlot(p, this.RenderSize)))
{
// For each subsequent stroke plot, we need to start a new figure.
//
if (this.Sketch.DrawingPoints.Any())
this.Sketch.StartNewFigure(ppc.First().Position);
foreach (var point in ppc)
{
await Task.Delay(100);
this.Sketch.DrawingPoints.Add(point.Position);
}
}
completionSource.SetResult(true);
}
catch (Exception e)
{
completionSource.SetException(e);
}
});
return (Task)completionSource.Task;
}
Note: the main work being done on the UI thread is just some lines being drawn on screen every 100ms.
A TaskCompletionSource is created as the puppet master. Look near the end and you'll see that it has a Task property that is returned to the caller. Returning Task satisfies the compilers needs and makes the method awaitable and asynchronous.
However, the Task is just a puppet, a proxy for the actual work going on in the UI thread.
See how in that main UI delegate I use the TaskCompletionSource.SetResult method to force a result into the Task (since returned to the caller) and communicate that work has finished.
If there's an error, I use SetException to 'pull another string' and make it appear that an exception has bubbled-up in the puppet Task.
The async-await subsystem knows no different and so it works as you'd expect.
Edit
As prompted by svick, if the method was designed to be callable only from the UI thread, then this would suffice:
/// <summary>
/// Begins a demonstration drawing of the asterism.
/// </summary>
public async Task PlayDemoAsync()
{
if (this.Sketch != null)
{
foreach (var ppc in this.Plots.Select(p => this.TransformPlot(p, this.RenderSize)))
{
// For each subsequent stroke plot, we need to start a new figure.
//
if (this.Sketch.DrawingPoints.Any())
this.Sketch.StartNewFigure(ppc.First().Position);
foreach (var point in ppc)
{
await Task.Delay(100);
this.Sketch.DrawingPoints.Add(point.Position);
}
}
}
}

A nice way to work the clean way #StephenCleary suggests even if you have to start from a worker thread for some reason, is to use a simple helper object. With the object below you can write code like this:
await DispatchToUIThread.Awaiter;
// Now you're running on the UI thread, so this code is safe:
this.textBox.Text = text;
In your App.OnLaunched you have to initialize the object:
DispatchToUIThread.Initialize(rootFrame.Dispatcher);
The theory behind the code below you can find at await anything;
public class DispatchToUIThread : INotifyCompletion
{
private readonly CoreDispatcher dispatcher;
public static DispatchToUIThread Awaiter { get; private set; }
private DispatchToUIThread(CoreDispatcher dispatcher)
{
this.dispatcher = dispatcher;
}
[CLSCompliant(false)]
public static void Initialize(CoreDispatcher dispatcher)
{
if (dispatcher == null) throw new ArgumentNullException("dispatcher");
Awaiter = new DispatchToUIThread(dispatcher);
}
public DispatchToUIThread GetAwaiter()
{
return this;
}
public bool IsCompleted
{
get { return this.dispatcher.HasThreadAccess; }
}
public async void OnCompleted(Action continuation)
{
if (continuation == null) throw new ArgumentNullException("continuation");
await this.dispatcher.RunAsync(CoreDispatcherPriority.Normal, () => continuation());
}
public void GetResult() { }
}