Will having a delay between canceling and disposing a CancellationTokenSource provide any assurance that IsCancellationRequested will be set to true?

Question

C# Windows UWP project

I have implemented CancellationTokenSource and CancellationToken in an async method that calls another method. This method contains a while loop which maintains the value of a bool variable as true until the token source is cancelled.

The async method is triggered by a mouse left button pressed event and is cancelled by a mouse left button released event occurring while using a ColorPicker control. The bool variable allows the color values to be sent to a device when true and prevents it when false.

By maintaining the value as true, the device receives varying color values continuously while the pointer is moved around the color picker as long as the mouse button remains down. Once the mouse button is released, the resulting false value (which gets set by the routine that sends the color values to the device) prevents further color messages from being sent to the device.

My code does what I want it too, but I’m concerned about potential side effects that could result if I have not implemented it correctly. I have seen at least one posting on this forum that indicates that the sequence: cancel, dispose and set to null can be used for the CancellationTokenSource. But it concerns me that I have a potentially endless while loop that depends entirely on receiving the cancellation token. So my question is whether disposing of a CancellationTokenSource too soon could prevent token.IsCanellationRequested from being set to true, and if so will adding a delay add any benefit?

The following are the related snippets from my code:

Global variables:

public static bool colorPickerPtrPressed = false;
static CancellationTokenSource cts = null;
static CancellationToken token;

Mouse button events:

private void ColorPicker_PtrPressedEvent(object sender, PointerRoutedEventArgs e)
{
    if(cts == null) cts = new CancellationTokenSource();
    token = cts.Token;

    var picker = sender as ColorPicker.ColorPicker;

    colorPickerPtrPressed = true;
    (picker.DataContext as SpheroViewModel).Color = picker.SelectedColor.Color;

    ColorChange(token);

}

private void ColorPicker_PtrReleasedEvent(object sender, PointerRoutedEventArgs e)
{
    if (cts != null)
    {
        cts.Cancel();
        Task.Delay(500).Wait(); // Allow some time for cancel to take effect
        cts.Dispose();
        cts = null;
    } 
}

Cancellation token methods:

public static async Task ColorChange(CancellationToken token)
{
    await Task.Run(() =>
    AllowColorChange(token), token);
}

public static void AllowColorChange(CancellationToken token)
{
        while (!token.IsCancellationRequested)
        {
            colorPickerPtrPressed = true; // Maintain value as true
            Task.Delay(100).Wait(); // allow color updates periodically
        }
    return;
}

Answer 1

So my question is whether having a delay between cancelling and disposing a CancellationTokenSource, as I have done in "ColorPicker_PtrReleasedEvent" below, will provides any assurance that the while loop will terminate?

No. The cancellation model is cooperative and calling Cancel simply provides a notification of cancellation by setting the IsCancellationRequested property of all tokens to true.

It's then up to any cancellable API, i.e. any method that accepts a CancellationToken, to monitor the value of this property and respond to the cancellation request.

So ColorPicker_PtrReleasedEvent cannot assure that the while loop will terminate in AllowColorChange.

Answer 2

As recommended by TZ I modified the last three methods to await a canceled flag from the AllowColorChange(token) method and then used that result as a permissive to dispose() of the CancellationTokenResult and set it to null. If anyone sees a problem with what I have done, please let me know. The following is the modified code, which appears to work well:

    private void ColorPicker_PntrReleasedEvent(object sender, PointerRoutedEventArgs e)
    {
        if (cts != null)
        {
            cts.Cancel();
            //Task.Delay(200).Wait(); // Allow some time for cancel to take effect
            //cts.Dispose();
            //cts = null;
        }
    }

    public static async Task ColorChange(CancellationToken token)
    {
        bool task = false;
        task = await Task.Run<bool>(() =>
        AllowColorChange(token), token);
        if (task)
        {
            cts.Dispose();
            cts = null;
        }
        else
        {
            // Shouldn't ever reach this point
            bool isBrkPnt = true;
        }
    }

    public static async Task<bool> AllowColorChange(CancellationToken token)
    {
            while (!token.IsCancellationRequested)
            {
                colorPickerPtrPressed = true; // Maintain value as true
                await Task.Delay(100); // allow color updates periodically
            }
        return true; // signal that task was canceled
    }

}

Answer 3

After implementing recommendations suggested by Theodor Zoulias, the final code is now as shown below. It can be seen that no arbitrary delay is used between canceling and disposing the CancellationTokenSource, but rather the disposal is moved to a catch{} block that is triggered by an OperationCanceledException resulting from throwing token.ThrowIfCancellationRequested(); from within the while() loop, which was moved inside a try{} block and it's test parameter set to true. It is no longer necessary to test for the value of token.IsCancellationRequested as a parameter of the while loop. This coding ensures that the disposal will not occur until the task within the try{} block is canceled.

     private void ColorPicker_PntrPressedEvent(object sender, PointerRoutedEventArgs e)
    {
        if(cts == null) cts = new CancellationTokenSource();
        token = cts.Token;

        var picker = sender as ColorPicker.ColorPicker;

        colorPickerPtrPressed = true; // True allows new values of color to be sent to device
        (picker.DataContext as SpheroViewModel).Color = picker.SelectedColor.Color;

        ColorChange(token); // Don't await this

    }

    private void ColorPicker_PntrReleasedEvent(object sender, PointerRoutedEventArgs e)
    {
        if (cts != null)
        {
            cts.Cancel();
        }
    }

    public static async Task ColorChange(CancellationToken token)
    {
        try
        {
            await Task.Run(async () =>
            {
                while (true)
                {
                    token.ThrowIfCancellationRequested();
                    colorPickerPtrPressed = true; // Maintain value as true while mouse button remains pressed
                    await Task.Delay(100, token); // allow color updates periodically
                }
            }, token);
        }
        catch (OperationCanceledException ex) when (ex.CancellationToken == token) // includes TaskCanceledException
        {
            if (cts != null) // Shouldn't arrive here if it is null but check just in case
            {
                try
                {
                    cts.Dispose();
                    cts = null;
                }
                catch (ObjectDisposedException e)
                {
                    // Already disposed, do nothing
                    bool brkPnt = true;
                }
            }
        }
    }

}

}