ConfigureAwait(false) still continue on captured context when using Async Targeting Pack - by Oscar Hansson

Status : 

  Fixed<br /><br />
		This item has been fixed in the current or upcoming version of this product.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.


3
0
Sign in
to vote
ID 767008 Comments
Status Closed Workarounds
Type Bug Repros 2
Opened 10/11/2012 1:57:33 AM
Access Restriction Public

Description

Method body after call to await <task>.ConfigureAwait(false) will run on captured context when using Async Targeting Pack  for Visual Studio 11 v1.0.0 (.Net Framework 4.0 only). 

Expected beahvior using ConfigureAwait(false) on a task is that the method body after await statement would run in a threadpool thread (TaskScheduler.Default).

In Visual Studio 10 with Async CTP and in Visual Studio 11 with .NET Framework 4.5 this expected behaviour is seen.
Sign in to post a comment.
Posted by David [MSFT] on 11/7/2012 at 11:28 AM
Thanks for the report. This is fixed in the latest internal builds, and will be available in the next update of the Microsoft.Bcl.Async pack.
Posted by David [MSFT] on 11/6/2012 at 11:48 AM
Thanks for reporting this Oscar - we've confirmed that this is a bug, looks like we were ignoring the 'continueOnCapturedContext' parameter. We should have this fixed in the next update of the Microsoft.Bcl.Async package.

Regards

David Kean
BCL Team
Posted by Oscar Hansson on 10/24/2012 at 6:18 AM
I'm not sure that you could expect the same output from the two methods.

It's more clear to me what result to expect if we observe the thread id instead of task id. Modifying the two methods slightly, should result in same output behavior, that means both MainLines should NOT have the same id.

        public async void Test()
        {
            Debug.WriteLine("MainLine({0})", Thread.CurrentThread.ManagedThreadId);
            await TaskEx.Run(() =>
                {
                    Debug.WriteLine("Task({0})", Thread.CurrentThread.ManagedThreadId);
                }).ConfigureAwait(false);
            Debug.WriteLine("MainLine({0})", Thread.CurrentThread.ManagedThreadId);
        }

        public void Test2()
        {
            Debug.WriteLine("MainLine({0})", Thread.CurrentThread.ManagedThreadId);
            TaskEx.Run(() => Debug.WriteLine("Task({0})", Thread.CurrentThread.ManagedThreadId)).
                ContinueWith(antecedent =>
                {
                    Debug.WriteLine("MainLine({0})", Thread.CurrentThread.ManagedThreadId);
                }, TaskScheduler.Default);
        }

Example of expected output (VS 2012 on .NET 4.5 targeting .NET 4.5 Win7):
Test method 1:
MainLine(8)
Task(9)
MainLine(10)
Test method 2:
MainLine(8)
Task(10)
MainLine(10)

Example of unexpected output (VS 2012 on .NET 4.5 targeting .NET 4.0 with Async Targeting Pack Win7):
Test method 1:
MainLine(10)     <----------- Main thread
Task(6)
MainLine(10)     <----------- Should NOT run on the main thread (id=10)
Test method 2:
MainLine(10)
Task(11)
MainLine(11)

Posted by Jay B. Harlow on 10/23/2012 at 7:45 AM
I've noticed the same thing with both the async targeting pack (Silverlight 5) and the new microsoft.bcl.async pack (Silverlight 4) (http://blogs.msdn.com/b/bclteam/archive/2012/10/19/using-async-await-without-net-framework-4-5.aspx)

I would expect the same output from both of these routines, however they don't match!

        public async void Test()
        {
            Debug.WriteLine("MainLine({0})", Task.CurrentId);
            await TaskEx.Run(() => Debug.WriteLine("Task({0})", Task.CurrentId)).ConfigureAwait(false);
            Debug.WriteLine("MainLine({0})", Task.CurrentId);
        }

        public void Test2()
        {
            Debug.WriteLine("MainLine({0})", Task.CurrentId);
            TaskEx.Run(() => Debug.WriteLine("Task({0})", Task.CurrentId)).ContinueWith(antecedent =>
            {
                Debug.WriteLine("MainLine({0})", Task.CurrentId);
            });
        }

Jay
Posted by Helen [MSFT] on 10/11/2012 at 2:36 AM
Thanks for your feedback.

We are rerouting this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.
Posted by Helen [MSFT] on 10/11/2012 at 2:27 AM
Thank you for your feedback, We are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly (http://support.microsoft.com/)