Await with sync method.

Hello, I'm trying to sort the things out with the new multithreading model using the await and async keywords.
Now I have a project where I have a lengthly method that I'd preferred to call asyncronously:

Code:

---

private void StoreData(List<string> data)
{
  ...
}

---

Now, I want this method to be called both syncronously and asyncronously depending on certain logic.
I've made another method

Code:

---

private async void StoreDataAsync(List<string> data)
{
  await ... // ???
}

---

Now, what should I put into the StoreDataAsync to call the StoreData logic asyncronously?
I certainly can make it work using the old multithreading model, but is it possible to make it work the way I described?

Hello,

Here is a good reference which may help.

Async/Await FAQ

I'm guessing you haven't quite grasped how async methods work so I'll provide a small example:-

C Code:

//
        private async void button1_Click(object sender, EventArgs e)
        {
            int i=0;
 
            while(true) 
            {
                i++;
                listBox1.Items.Add(i);
 
                
                await Task.Delay(1);
            }
 
 
 
        }

That code for a Button's Click event. It adds items to a ListBox asynchronously. The await keyword yields to the calling method so it doesn't lock up the UI. Also for await to work, the method in which its being used must have the async modifier in its declaration.

That's true, I haven't quite grasped this new feature.
Basically, what I need is to call my sync method asyncronously.
I have a sync method Foo(object param), what I need is to write an async wrapper around it in order to be able to call it asyncronously (without changing the Foo body. Is this possible with async/await or it's easier to use it the old way?

Well to be honest, I can't say which is better. If this method Foo returns a value then you can handle getting this return value much more elegantly with the new way but it will require you to alter the method itself, at least to yield via Task.Delay if there's a loop in there somewhere. If it doesn't return a value then it might just be easier to thread it the old way as it wouldn't require you to change your method. You see this new way of writing asynchronous methods takes away all the ugliness of using callbacks as a way of getting notification when an asynchronous task is finished. Essentially you're writing asynchronous code in a synchronous style.