I thought one of the points about async/await is that when the task completes, the continuation is run on the same context when the await was called, which would, in my case, be the UI thread.
So for example:
Debug.WriteLine("2: Thread ID: " + Thread.CurrentThread.ManagedThreadId);
await fs.ReadAsync(data, 0, (int)fs.Length);
Debug.WriteLine("3: Thread ID: " + Thread.CurrentThread.ManagedThreadId);
I would NOT expect this:
2: Thread ID: 10
3: Thread ID: 11
What gives? Why is the thread ID for the continuation different than the UI thread?
According to this article[^] I would need to explicitly call ConfigureAwait to change the behavior of the continuation context!
When you
await
, by default theawait
operator will capture the current "context" and use that to resume theasync
method.This "context" is
SynchronizationContext.Current
unless it isnull
, in which case it isTaskScheduler.Current
. (If there is no currently-running task, thenTaskScheduler.Current
is the same asTaskScheduler.Default
, the thread pool task scheduler).It's important to note that a
SynchronizationContext
orTaskScheduler
does not necessarily imply a particular thread. A UISynchronizationContext
will schedule work to the UI thread; but the ASP.NETSynchronizationContext
will not schedule work to a particular thread.I suspect that the cause of your problem is that you are invoking the
async
code too early. When an application starts, it just has a plain old regular thread. That thread only becomes the UI thread when it does something likeApplication.Run
.The
await
expression will use the value ofSynchronizationContext.Current
to return control flow back to the thread on which it occurred. In cases where this isnull
it will default to theTaskScheduler.Current
. The implementation relies solely on this value to change the thread context when theTask
value completes. It sounds like in this case theawait
is capturing a context that isn't bound to the UI thread