.Net why does Threading.Task.Task still block my UI?

Question

Hi all,

I'm currently writing an application that will control positioning of a measurement device. Because of the hardware involved I need to poll for the current position value constantly while running the electric motor. I'm trying to build the class responsible for this so that it does the polling on a background thread and will raise an event when the desired position is reached. The idea being that the polling won't block the rest of the application or the GUI. I wanted to use the new Threading.Task.Task class to handle all the background thread plumbing for me.

I haven't got the hardware yet, but have build a test stub to simulate this behavior. But when I run the application like this the GUI still blocks. See a simplified example of the code below (not complete and not using separate class for device control). The code has a sequence of measurement steps, the application has to position and then measure for each step.

public partial class MeasurementForm: Form
{
    private MeasurementStepsGenerator msg = new MeasurementsStepGenerator();
    private IEnumerator<MeasurementStep> steps;

    // actually through events from device control class
    private void MeasurementStarted()
    {
        // update GUI
    }

    // actually through events from device control class
    private void MeasurementFinished()
    {
        // store measurement data
        // update GUI
        BeginNextMeasurementStep();
    }

    private void MeasurementForm_Shown(object sender, EventArgs e)
    {
        steps = msg.GenerateSteps().GetEnumerator();
        BeginNextMeasurementStep();
    }        
    ...
    ...

    private void BeginNextMeasurementStep()
    {
        steps.MoveNext();
        if (steps.Current != null)  
        { 
            MeasurementStarted();
            MeasureAtPosition(steps.Current.Position); 
        }
        else    
        { 
            // finished, update GUI
        }
    }

    // stub method for device control (actually in seperate class)
    public void MeasureAtPosition(decimal position)
    {
        // simulate polling
        var context = TaskScheduler.FromCurrentSynchronizationContext();
        Task task = Task.Factory.StartNew(() =>
        {
            Thread.Sleep(sleepTime);
        }, TaskCreationOptions.LongRunning)
        .ContinueWith(_ =>
        {
            MeasurementFinished();
        }, context);
    }
}

I would expect the Task to run the Thread.Sleep command on a background thread so control returns to the main thread immediately and the GUI doesn't get blocked. But the GUI still gets blocked. It's like the Task runs on the main thread. Any ideas on what I'm doing wrong here?

Thanks

Answer 1

Because your continuation task (via ContinueWith) specifies a TaskScheduler the TPL uses that for all other tasks kicked off further down the call stack regardless of whether you actually specified it. In other words, calls to Task.Factory.StartNew originating from the Action delegate specified in ContinueWith will automatically use the specified TaskScheduler by default.

I have modified your code to help you better visualize what is going on.

private void BeginOperation()
{
    System.Diagnostics.Trace.WriteLine("BeginOperation-top " + Thread.CurrentThread.ManagedThreadId);
    var context = TaskScheduler.FromCurrentSynchronizationContext();
    Task task = Task.Factory.StartNew(() =>
    {
        System.Diagnostics.Trace.WriteLine("  BeginOperation-StartNew-top " + Thread.CurrentThread.ManagedThreadId);
        Thread.Sleep(5000);
        System.Diagnostics.Trace.WriteLine("  BeginOperation-StartNew-bottom " + Thread.CurrentThread.ManagedThreadId);
    }, TaskCreationOptions.LongRunning)
    .ContinueWith(_ =>
    {
        System.Diagnostics.Trace.WriteLine("  BeginOperation-ContinueWith-top " + Thread.CurrentThread.ManagedThreadId);
        EndOperation();
        System.Diagnostics.Trace.WriteLine("  BeginOperation-ContinueWith-bottom " + Thread.CurrentThread.ManagedThreadId);
    }, context);
    System.Diagnostics.Trace.WriteLine("BeginOperation-bottom " + Thread.CurrentThread.ManagedThreadId);
}

private void EndOperation()
{
    System.Diagnostics.Trace.WriteLine("EndOperation-top " + Thread.CurrentThread.ManagedThreadId);
    BeginOperation();
    System.Diagnostics.Trace.WriteLine("EndOperation-bottom " + Thread.CurrentThread.ManagedThreadId);
}

I examined the code in ContinueWith via Reflector and I can confirm that it is attempting to discover the execution context used by the caller. Yes, believe it or not, and despite your natural intuition to the contrary, that is exactly what it is doing.

I am still investigating a workaround. I am somewhat convinced the solution has something to do with ExecutionContext.SuppressFlow and ExecutionContext.RestoreFlow, but I am not currently having any luck.

Regardless, I think any solution is going to end up being a lot more complicated then simply creating a dedicated thread to do the hardware polling.

Answer 2

Brian Gideon is correct as to the cause of the problem - recursively created tasks are getting started with their current task scheduler set to a SynchronizationContextTaskScheduler which specifies the main thread. Running them in the main thread is obviously not what you want.

You can fix this by using one of the overloads for TaskFactory.StartNew which accepts a task scheduler and pass it TaskScheduler.Default.