Блокировка ресурсов между итерациями основного потока (Async/Await)

Ресурс имеет собственный код блокировки и разблокировки для обработки параллелизма. Ресурс может быть изменен любым потоком.

Есть желтый флаг. Я считаю, что дизайн, в котором вы защищаете ресурсы (а не заставляете их защищать себя), обычно лучше в долгосрочной перспективе.

Когда кнопка button1 нажата, ее обработчик выполняет некоторое изменение самого r, а затем асинхронно вызывает _IndependentResourceModifierAsync(), который выполняет некоторое изменение r в порожденной задаче. _IndependentResourceModifierAsync() получает блокировку r перед тем, как сделать это. Кроме того, поскольку обработчик возится с самим r, он также получает блокировку r.

И есть красный флаг. Рекурсивные блокировки почти всегда плохая идея. Я объясняю свои рассуждения в своем блоге.

Есть еще одно предупреждение, которое я заметил относительно дизайна:

Если нажата кнопка1 или кнопка2, когда ресурс заблокирован основным потоком, будет выдано исключение. (Нельзя использовать монитор или мьютекс, потому что они управляются потоками)

Мне это не кажется правильным. Есть ли другой способ сделать это? Отключение кнопок при изменении состояния кажется гораздо более приятным подходом.

Я настоятельно рекомендую провести рефакторинг, чтобы удалить требование рекурсии блокировки. Затем вы можете использовать SemaphoreSlim с WaitAsync для асинхронного получения блокировки и Wait(0) для «попытки блокировки».

Таким образом, ваш код будет выглядеть примерно так:

class Resource
{
  private readonly SemaphoreSlim mutex = new SemaphoreSlim(1);

  // Take the lock immediately, throwing an exception if it isn't available.
  public IDisposable ImmediateLock()
  {
    if (!mutex.Wait(0))
      throw new InvalidOperationException("Cannot acquire resource");
    return new AnonymousDisposable(() => mutex.Release());
  }

  // Take the lock asynchronously.
  public async Task<IDisposable> LockAsync()
  {
    await mutex.WaitAsync();
    return new AnonymousDisposable(() => mutex.Release());
  }
}

async void button1Click(..)
{
  using (r.ImmediateLock())
  {
    ... // mess with r
    await _IndependentResourceModiferUnsafeAsync();
  }
}

async void button2Click(..)
{
  using (r.ImmediateLock())
  {
    await _IndependentResourceModiferUnsafeAsync();
  }
}

async Task _IndependentResourceModiferAsync()
{
  using (await r.LockAsync())
  {
    await _IndependentResourceModiferUnsafeAsync();
  }
}

async Task _IndependentResourceModiferUnsafeAsync()
{
  ... // code here assumes it owns the resource lock
}

Я много искал кого-то еще, у кого была эта проблема, но ничего не вышло. Это, вероятно, означает, что я слишком усложняю вещи, но мне любопытно, что люди говорят об этом.

Долгое время это было невозможно (вообще, точка, точка). С .NET 4.5 это возможно, но некрасиво. Это очень сложно. Я не знаю, чтобы кто-нибудь действительно делал это в производственной среде, и я определенно не рекомендую это делать.

Тем не менее, я играл с асинхронными рекурсивными блокировками как пример в моей библиотеке AsyncEx (он никогда не будет частью общедоступного API). Вы можете использовать его следующим образом (следуя соглашению AsyncEx об уже отмененных токены, действующие синхронно):

class Resource
{
  private readonly RecursiveAsyncLock mutex = new RecursiveAsyncLock();
  public RecursiveLockAsync.RecursiveLockAwaitable LockAsync(bool immediate = false)
  {
    if (immediate)
      return mutex.LockAsync(new CancellationToken(true));
    return mutex.LockAsync();
  }
}

async void button1Click(..)
{
  using (r.LockAsync(true))
  {
    ... // mess with r
    await _IndependentResourceModiferAsync();
  }
}

async void button2Click(..)
{
  using (r.LockAsync(true))
  {
    await _IndependentResourceModiferAsync();
  }
}

async Task _IndependentResourceModiferAsync()
{
  using (await r.LockAsync())
  {
    ...
  }
}

Код для RecursiveAsyncLock не очень длинный, но думать о нем ужасно сложно. Он начинается с неявного асинхронного контекста, который я описываю в подробно в моем блоге (что трудно понять само по себе), а затем использует пользовательские ожидания для «внедрения» кода в нужное время в методы конечного пользователя async.

Вы находитесь прямо на краю того, с чем кто-либо уже экспериментировал. RecursiveAsyncLock вообще тщательно не тестируется и, вероятно, никогда не будет.

Действуй осторожно, исследователь. Вот драконы.

Я считаю, что асинхронная блокировка с повторным входом, которая ведет себя достаточно хорошо, невозможна. Это связано с тем, что когда вы запускаете асинхронную операцию, вам не требуется немедленно ее await.

Например, представьте, что вы изменили свой обработчик событий на что-то вроде этого:

private async void button1_Click(object sender, EventArgs e)
{
    if (!r.TryLock())
        throw InvalidOperationException("Resource already acquired");
    try
    {
        var task = _IndependentResourceModiferAsync();
        // Mess with r here
        await task;
    }
    finally
    {
        r.Unlock();
    }
}

Если бы блокировка была асинхронно повторной, код, работающий с r в обработчике событий, и код в вызываемом асинхронном методе могли бы работать одновременно (поскольку они могут выполняться в разных потоках). Это означает, что такой замок не будет безопасным.

Я думаю, вам следует взглянуть на SemaphoreSlim (со счетчиком из 1):

• Он не реентерабельный (не принадлежит потоку)
• Он поддерживает асинхронное ожидание (WaitAsync)

У меня сейчас нет времени проверять ваш сценарий, но я думаю, что он подойдет.

РЕДАКТИРОВАТЬ: я только что заметил этот вопрос:

Потому что, когда асинхронный метод продолжает работу после ожидания, он восстанавливает состояние стека.

Нет, это абсолютно не так. Это легко показать — добавьте асинхронный метод, который реагирует на нажатие кнопки, например:

public void HandleClick(object sender, EventArgs e)
{
    Console.WriteLine("Before");
    await Task.Delay(1000);
    Console.WriteLine("After");
}

Установите точку останова для обоих ваших вызовов Console.WriteLine — вы заметите, что до await у вас есть трассировка стека, включая код «обработки кнопок» в WinForms; после этого стек будет выглядеть совсем иначе.