Tag Archives: async

Manually Implementing a Parallel.For Loop

Why would you do this?

PCLs don’t support them

Okay – How?

List<Task> myTasks = new List<Task>();

for (int i = 1; i <= 10; i++) // Artificially implement Parallel.For because this is a PCL
{
    myTasks.Add(Task.Run(() =>
    {
        // Task logic goes here
    }));
}

await Task.WhenAll(myTasks);

Small victories.

TaskCompletionSource

I’ve had a couple of problems recently, where I’ve had tasks or asynchronous methods and they don’t quote fit into the architecture that I find myself in. I’d come across the TaskCompletionSource before, but hadn’t realised how useful it was. Basically, a TaskCompletionSource allows you to control when a task finishes; and allows you to do so in a synchronous, or asynchronous fashion. What this gives you is precise control over when an awaited task finishes.

UWP

Consider the following code in UWP. Basically, what this does is execute an anonymous function on the UI thread:


await CoreApplication.MainView.CoreWindow.Dispatcher.RunAsync(Windows.UI.Core.CoreDispatcherPriority.High, async () => 
{
    await MyAyncFunc();
}
System.Diagnostics.Debug.WriteLine("After MyAsyncFunc");

The problem here is that executing an anonymous async function in the above scenario doesn’t work. However, using the TaskCompletionSource, we can bypass that whole conversation:

TaskCompletionSource<bool> tcs = new TaskCompletionSource<bool>();

await CoreApplication.MainView.CoreWindow.Dispatcher.RunAsync(Windows.UI.Core.CoreDispatcherPriority.High, async () => 
{
    await MyAyncFunc();
    System.Diagnostics.Debug.WriteLine("After MyAsyncFunc");

    tcs.SetResult(true);
});
await tcs.Task;

Now the function will return when the the TaskCompletionSource.SetResult has been called.

Event based

The second scenario where this is useful is where you are trying to use an event based architecture within an async / await scenario. The following example is a little contrived, but it does illustrate the point:

    class Program
    {
        private static Timer _tmr = new Timer();
        private static TaskCompletionSource<bool> _tcs;

        static void Main(string[] args)
        {
            var tmr = StartTimer();

            Console.WriteLine("Before wait...");
            tmr.Wait();

            Console.WriteLine("After wait...");
        }        

        private static async Task StartTimer()
        {            

            _tmr.Interval = 3000;
            _tmr.Elapsed += _tmr_Elapsed;
            _tmr.Start();

            _tcs = new TaskCompletionSource<bool>();
            await _tcs.Task;
        }

        private static void _tmr_Elapsed(object sender, ElapsedEventArgs e)
        {
            _tcs.SetResult(true);
        }
    }

Potentially, a more real world example of this is when you might want to wrap an API in an async/await.

Control over exactly when a task finishes, and the ability to await async void methods

The final scenario where this can be useful is where you either want to await an `async void` method, or where you have a specific part of a method or process that you want to await.

The following code illustrates how to effectively await an async void method:

    class Program
    {        
        private static TaskCompletionSource<bool> _tcs;

        static void Main(string[] args)
        {
            _tcs = new TaskCompletionSource<bool>();
            BackgroundFunction();

            _tcs.Task.Wait();

            Console.WriteLine("Done");
        }        

        private static async void BackgroundFunction()
        {
            for (int i = 1; i <= 10; i++)
            {
                Console.WriteLine($"Processing: {i}");
                await DoStuff();
            }
            _tcs.SetResult(true);
        }

        private static async Task DoStuff()
        {
            await Task.Delay(500);
            
        }

    }

Finally, here is a parallel for loop:

        static void Main(string[] args)
        {
            Parallel.For(1, 3, (i) =>
            {
                BackgroundFunction();
            });

            Console.WriteLine("Done");
        }        

Imagine that BackgroundFunction is performing a long running task where a specific condition needs to return control. There are obviously combinations of functions in the TPL (WaitAll, WhenAll, WhenAny and WhenAll), however, these rely on the whole task, or a set of tasks, completing. Again, the below example is contrived, but it illustrates the granular control over the task that you have.

        static void Main(string[] args)
        {
            _tcs = new TaskCompletionSource<bool>();

            for (int i = 1; i <= 2; i++)
            {
                BackgroundFunction();
            }

            _tcs.Task.Wait();            

            Console.WriteLine("Done");
        }        

        private static async void BackgroundFunction()
        {
            for (int i = 1; i <= 10; i++)
            {
                Console.WriteLine($"Processing: {i}");
                await DoStuff();

                if (i == 7)
                {
                    _tcs.TrySetResult(true);
                    return;                    
                }
            }            
        }

I will re-iterate again, I realise that in the above example, there are better ways to achieve this, and the example is purely for illustration.

Conclusion

Generally speaking, the simplest and most robust code comes from using the task architecture in the way it was designed: that is, use async / await inside a method that returns a Task. I’m not suggesting in this post that the methods I’ve described should replace that; but there are situations where that might not fit.

Aknowledgements

I used the following posts heavily while writing this:

Awaiting the CoreDispatcher
The Nature of TaskCompletionSource
Real life scenarios for using TaskCompletionSource?
Task Parallelism

Deleting Files in a Storage Folder Using UWP

Just a little helper method that I used in a recent project to delete files, given a particular name, and excluding a provided list of files:

        internal static async Task DeleteTempFiles(ObservableCollection<StorageFile> exceptionFiles, StorageFolder folder, string fileNameStartsWith)
        {
            var files = (await folder.GetFilesAsync())
                .Where(p => p.DisplayName.StartsWith(fileNameStartsWith)
                && !exceptionFiles.Any(e => e.DisplayName == p.DisplayName));            

            foreach(var file in files)
            {
                await file.DeleteAsync(StorageDeleteOption.Default);                
            }
        }

You can call it like this:

	await FileHelper.DeleteTempFiles(Files, KnownFolders.PicturesLibrary, "_tmpFile");

It will delete all files in the Pictures folder starting with _tmpFile, and exclude anything in the Files collection.

Cannot change thread mode after it is set

I recently published this article on using asynchonous methods within a Windows Game, and this article on enabling consumables within a Windows Game

However, I encountered a problem when I tried to use these two methods in combination. My code looked something like this:

var result = MessageBoxHelper.MsgBox.ShowAsync(string.Format("You do not have sufficient widgets for this.\n" +
    "Would you like to purchase more?"), MessageBoxButton.YesNo).ContinueWith(async (answer) =>
{
    if (answer.Result == MessageBoxResult.Yes)
    {
        bool purchTask = await Purchase.RequestProductPurchase(WIDGETS);

However, when I ran this; I got the following exception:

cannotchangethread

This is a marginally documented error:

By Microsoft and by Stack Overflow

I could call the function Purchase.RequestProductPurchase directly, but not, for some reason, in conjunction with ContinueWith. I tried this combination in a basic console application:

        static void Main(string[] args)
        {
            continueWithTest();
        }

        private static void continueWithTest()
        {
            MyAsyncFunc().ContinueWith(async (a) =>
            {
                Console.WriteLine("test");
                await Task.Delay(2000);                
            }).Wait();
            Console.ReadLine();
        }
        static async Task MyAsyncFunc()
        {
            await Task.Delay(2000);
            Console.WriteLine("Test1");
    }

And it worked fine. Based on what is available to read on the web, it looks like the threading model is, in some way, different when using ContinueWith. Although, it would appear that if you specify the TaskScheduler.Current, you should be able to use this in place of await, but that seems to make no difference.

The fix, as so many people are quick to point out, is use await:

        private void MakePurchase(int cost, Action onSuccess, bool interactive)
        {
            if (App.settings.CashPot.Total > cost)
            {
                App.settings.CashPot.Total -= cost;
                onSuccess.Invoke();                
            }
            else if (interactive)
            {
                InsufficientFunds(cost, onSuccess);
            }
        }


        private async void InsufficientFunds(int cost, Action onSuccess)
        {
            var result = await MessageBoxHelper.MsgBox.ShowAsync(string.Format("You do not have sufficient funds for this.\n" +
                "Would you like to purchase additional cash?"),
                "Insufficient Funds", MessageBoxButton.YesNo);                
                            
            if (result == MessageBoxResult.Yes)
            {
                bool purchTask = await Purchase.RequestProductPurchase(WIDGETS);

                MakePurchase(cost, onSuccess, false);
            }
        }

Detecting multiple gesture types using Monogame in Windows 8

Gestures in this environment are hard. Ridiculously hard. There is a ReadGesture function, but it doesn’t work. Let’s imagine that you want to detect the following gestures:

Tap
Double Tap
Drag

Not exactly complex. We’ll need to know some basic information about each gesture:

Tap: where have we tapped
Double tap: where have we double tapped (and that the two taps are in the same location)
Drag: the start and end positions of the drag.

Let’s have a look at some code:

     
TouchPanel.EnabledGestures =
GestureType.FreeDrag | GestureType.DragComplete | GestureType.DoubleTap | GestureType.Tap;

while (TouchPanel.IsGestureAvailable)
{
    GestureSample gs = TouchPanel.ReadGesture();
    switch (gs.GestureType)
    {
        case GestureType.FreeDrag:
            System.Diagnostics.Debug.WriteLine(string.Format("FreeDrag: {0}", gs.Position));
            break;

        case GestureType.DragComplete: 
            System.Diagnostics.Debug.WriteLine(string.Format("DragComplete: {0}", gs.Position));

            break;

        case GestureType.DoubleTap:
            System.Diagnostics.Debug.WriteLine("DoubleTap");

            break;

        case GestureType.Tap:
            System.Diagnostics.Debug.WriteLine("Tap");

            break;

    }
}

So, let’s run this and see what we get. We certainly get all the gestures. However, there are the following issues:

    1. The DragComplete doesn’t provide any information at all, other than the fact that the drag isn’t taking place anymore

    2. The drag works in bursts, so you get many drag events for a single drag

    3. The Tap event fires, but a Double Tap doesn’t replace the Tap, so you get both.

There’s a bit of rolling-your-own here. Let’s start with the drag, because it’s actually the easiest problem to solve. We know when the use finishes dragging, so a simple variable to say that they are dragging and where they started will solve most of this problem:

    private Vector2? dragStart = null;

Why is it nullable? Well, this variable stores two separate states: whether the user is dragging, and where they started.

Next, we need to know where they were last (if anyone from Microsoft ever reads this, please feel free to give a detailed description in the comments why this hoop jumping is necessary!):

    private Vector2? lastPosition = null;

Then we need to store and check these variables; here’s the new section of the switch statement:

    case GestureType.FreeDrag:
                                System.Diagnostics.Debug.WriteLine(string.Format("FreeDrag: {0}", gs.Position));
                        
        if (!dragStart.HasValue)
        {
            dragStart = gs.Position;
        }
        
        lastPosition = gs.Position;
            break;

       case GestureType.DragComplete:                    

           System.Diagnostics.Debug.WriteLine(string.Format("DragComplete: {0}", gs.Position));
                       
           if (dragStart.HasValue)
           {
               var gsDragDelta = lastPosition - dragStart.Value;
               if (gsDragDelta.Value.LengthSquared() > DRAG_TOLERANCE)
               {
                   if (gsDragDelta.Value.X != 0 || gsDragDelta.Value.Y != 0)
                   {
                       dragStart = null;
                       // Do stuff on drag complete
                       break;

That handles the drag. Next, the tap. Handling the Tap is easy, but what if, as I did, you want to handle Tap to do one thing, and Double Tap to do another? This fried my brain for a while; then something occurred to me. What if you delay the action:

    
    case GestureType.DoubleTap:    
        dblTap = true;
        // Do stuff on Double tap                  
        System.Diagnostics.Debug.WriteLine("DoubleTap");
        Task.Delay(100).ContinueWith((args) => { dblTap = false; });
        break;

    case GestureType.Tap:
        Task.Delay(100).ContinueWith((args) =>
        {
            if (!dblTap)
            {
                // DO stuff on Tap                
                System.Diagnostics.Debug.WriteLine("Tap");
            }
        });
        break;

I imagine the delay needs to be experimented with. 100ms seems to work for me.

As usual, if you have any suggestions, comments, or ways to do this better then please leave a comment.