0

Имеется такой код:

static StorageFolder Folder = ApplicationData.Current.LocalFolder;

public static async Task<StorageFile> GetFile(string path)
{
    try
    {
        return await Folder.CreateFileAsync(path, CreationCollisionOption.OpenIfExists);    
    }
    catch (Exception e)
    {
        throw new Exception(e.Message);
    }
}

С помощью которого выполняются некоторые действия с файлом.

По какой-то причине при заходе в этот метод происходит зависание - процесс висит и ничего не происходит. Ни исключений, ничего.

Подскажите, пожалуйста, в чем проблема и как её решить.

updt. Вызывающий метод:

var temp = DataManager.LoadObject<ObservableCollection<CheckingResult>>(await DataManager.GetFile(Path.FilePath)).Result
bodynar
  • 324
  • 1
  • 10
  • 4
    Эээ, а зачем ловить исключение, чтобы тут же его снова бросить (потеряв при этом его настоящий тип)? – VladD Apr 14 '16 at 13:41
  • Добавьте в вопрос код, который вызывает GetFile. – andreycha Apr 14 '16 at 14:16

3 Answers3

3

Ошибка тут:

var temp = (some code).Result

Вызов Result останавливает текущий поток до тех пор пока задача не завершится. Но для выхода из оператора await нужен работающий поток!

Отсюда и взаимоблокировка.

Никогда не вызывайте Task.Result или Task.Wait() в потоке UI!

Pavel Mayorov
  • 58,537
1

Возможно, вы вызываете метод из UI-потока без ключевого слова await и у вас происходит взаимоблокировка UI-потока и потока, в котором открывается файл. Метод должен использоваться следующим образом:

var file = await YourClass.GetFile(yourPath);

По этой теме рекомендую хорошую статью (англ. яз.), а конкретно раздел Async All the Way

Artem Flotsky
  • 189
  • Да, эта ошибка имеется, но если это опустить, файл должен загрузиться через некоторое время (там не так уж и много информации, простой .dat'ник с сериализованными данными) – bodynar Apr 14 '16 at 18:12
  • Пропуск ключевого слова await сам по себе не приводит к взаимоблокировке – Pavel Mayorov Apr 15 '16 at 06:13
  • @PavelMayorov, сам по себе нет, в вашем ответе тоже речь про UI-поток. Очевидно, что без await только через Result и можно достать результат, поэтому не вижу у нас с вами противоречий – Artem Flotsky Apr 15 '16 at 07:10
  • @ArtemFlotsky нет, словосочетание "без await" означает не использование .Result - а поведение "вызвал и забыл". Такое поведение рождает гонки, но не взаимоблокировку. – Pavel Mayorov Apr 15 '16 at 07:14
1

Async/await в C#: подводные камни

Если не нужен вызов внутри потока UI предпочтительнее использовать .ConfigureAwait(false); 

 return await Folder.CreateFileAsync(path, CreationCollisionOption.OpenIfExists).ConfigureAwait(false);

В статье как раз описан твой случай.

Ну и конечно лучше использовать await вместо Result

Если вы разрабатываете стороннюю библиотеку, очень важно всегда настраивать await таким образом, чтобы остальная часть метода была выполнена произвольным потоком из пула. Другими словами, в коде сторонних библиотек всегда необходимо добавлять ConfigureAwait(false).

В первую очередь, сторонние библиотеки обычно не работают с UI контролами (если конечно это не UI библиотека), поэтому нет никакой необходимости связывать UI поток. Вы можете немного увеличить производительность если позволите CLR выполнять ваш код любым потоком из пула. Во-вторых, используя дефолтную имплементацию (или явно проставляя ConfigureAwait(true)), вы оставляете потенциальную дыру для дедлоков. Рассмотрим следующий пример:

private async void button1_Click(object sender, EventArgs e)
{
    int result = DoSomeWorkAsync().Result; // 1
}

private async Task<int> DoSomeWorkAsync()
{
    await Task.Delay(100).ConfigureAwait(true); //2
    return 1;
}

Клик по кнопке здесь приводит к дедлоку. UI поток стартует новый I/O поток на строке «2» и уходит в спящий режим на строке «1», ожидая завершения работы. После того как I/O поток заканчивает выполнение, оставшаяся часть метода DoSomeWorkAsync передается на выполнение вызывающему (UI) потоку. Но тот в это время находится в спящем режиме, ожидая завершения метода. Дедлок.

Serginio
  • 1,057