Why does async method-callers behave strangely?

Question

I'm working on a Windows 8.1 store app in which the user can save text to a file.

I've been trying to understand how to best use async and await.

This is what I've come up with:

private async void userText_KeyDown(object sender, KeyRoutedEventArgs e)
    {            
        if (e.Key == Windows.System.VirtualKey.Enter)
        {
            if (addUserImput)
            {
                userStringlist.Add(userBox.Text);
                userBox.Text = "";
                addUserImput = false;
            }
            await WriteToFileAsync();
            addUserImput = true;
        }
    }

And the async-method looks like this:

private async Task WriteToFileAsync()
    {
        string name = "userStrings.txt";
        var option = CreationCollisionOption.ReplaceExisting;
        var folder = Windows.Storage.ApplicationData.Current.LocalFolder;
        var file = await folder.CreateFileAsync(name, option);
        await Windows.Storage.FileIO.WriteLinesAsync(file, userStringlist);            
    }

As soon as WriteToFileAsync reaches the await-keyword the execution will start over. In order to prevent duplicates in my list I had to add the if-statement.

It just strikes me as odd. I'm still new to this, so I might've missed something. Why does the keydown event resume from the top, doing work that has already been done?

My "workaround" works, I just don't get the logic behind the event's behaviour.

The `userText_KeyDown` method is async. Another keystroke may come in before the previous invocation of this event handler has completed. Your code should account for that. A related question: http://stackoverflow.com/q/19415646/1768303 — noseratio, Feb 28 '14 at 11:22

score 2 · Answer 1 · answered Feb 28 '14 at 19:18

Yes, that's how asynchronous solutions work. When you hit your first actually asynchronous operation (in this case, CreateFileAsync) the method returns to its caller, which returns to its caller, and it eventually works it's way out of the entire method and back up to your application's message loop. It then continues on processing other UI messages. Some of those messages may be key down events (and they could end up being run before your asynchronous operation is completed). Other events could be things like paint events or mouse click events that lets your form do whatever it needs to interact with the user. This is what prevents it from freezing.

What you want to do is to prevent the given section of code that you have from being run concurrently. If this weren't asynchronous this is something that you would generally solve using the lock keyword, but that isn't an option for an asynchronous method. What you need is some method of preventing access to the code until any other executions of that code block finish. Fortunately there are tools available to do this. You could use a boolean, as you are, but this is somewhat fragile and fairly easy to make a mistake with as the complexity of the application grows. A Semaphore is specifically designed for this task:

private SemaphoreSlim semaphore = new SemaphoreSlim(1);
private async void Bar()
{
    try
    {
        await semaphore.WaitAsync();
        //do stuff
    }
    finally
    {
        semaphore.Release();
    }
}

The SemaphoreSlim class has a WaitAsync method specifically designed for use in asynchronous methods, such as yours. You can wait until the semaphore is free, do your code, and then ensure that you release the semaphore when done so that other code can then move into the code block.

Async really isn't my thing, it seems. The method restarts even though I set the Semaphore parameter to 1 just as you did. Strange. The e.handled property did what my bool did but looks slightly more tasteful while debugging. Thanks for your time and effort, I'll try to implement this when I've gotten more experienced. — Ize, Feb 28 '14 at 20:30

score 0 · Accepted Answer · answered Feb 28 '14 at 19:09

0

You may need to use handled = true in this case . check if http://msdn.microsoft.com/en-us/library/system.windows.forms.keyeventargs.handled(v=vs.110).aspx works

answered Feb 28 '14 at 19:09

Zee

381
2
11

This did it for me. The method will no longer restart. Thank you! "e.handled" is set to false once the method has executed completely as well. Neat! – Ize Feb 28 '14 at 20:22
2

This doesn't actually address the case where the event handler is triggered again before the current handler has finished; it only prevents *other* handlers from the same event firing from being executed. *That* would only be helpful if the event handler is attached multiple times, in which case the solution is to not do that, rather than to try to ignore the other handlers. – Servy Feb 28 '14 at 20:33

Why does async method-callers behave strangely?

2 Answers2