SemaphoreSlim.WaitAsync 在尝试块之前/之后

Question

我知道在同步世界中，第一个 sn-p 是正确的，但是 WaitAsync 和 async/await 魔法又是什么？请给我一些 .net 内部结构。

await _semaphore.WaitAsync();
try
{
    // todo
}
finally
{
    _semaphore.Release();
}

或

try
{
    await _semaphore.WaitAsync();
    // todo
}
finally
{
    _semaphore.Release();
}

Answer 1

这是对 Bill Tarbell 的 LockSync 扩展方法的尝试改进，用于 SemaphoreSlim 类。通过使用值类型IDisposable 包装器和ValueTask 返回类型，可以显着减少超出SemaphoreSlim 类自身分配的额外分配。

public static ReleaseToken Lock(this SemaphoreSlim semaphore,
    CancellationToken cancellationToken = default)
{
    semaphore.Wait(cancellationToken);
    return new ReleaseToken(semaphore);
}

public static async ValueTask<ReleaseToken> LockAsync(this SemaphoreSlim semaphore,
    CancellationToken cancellationToken = default)
{
    await semaphore.WaitAsync(cancellationToken).ConfigureAwait(false);
    return new ReleaseToken(semaphore);
}

public readonly struct ReleaseToken : IDisposable
{
    private readonly SemaphoreSlim _semaphore;
    public ReleaseToken(SemaphoreSlim semaphore) => _semaphore = semaphore;
    public void Dispose() => _semaphore?.Release();
}

使用示例（同步/异步）：

using (semaphore.Lock())
{
    DoStuff();
}

using (await semaphore.LockAsync())
{
    await DoStuffAsync();
}

同步的Lock 始终是免分配的，无论是立即获取信号量还是在阻塞等待之后获取信号量。异步LockAsync 也是免分配的，但仅在同步获取信号量时（当它的CurrentCount 恰好是正时）。当存在争用且LockAsync 必须异步完成时，在标准SemaphoreSlim.WaitAsync 分配的基础上额外分配144 个字节（没有CancellationToken 是88 个字节，从.NET 5 开始，497 个字节带有可取消的CancellationToken 64位机）。

来自the docs：

从 C# 7.0 开始支持使用 ValueTask<TResult> 类型，并且不受任何版本的 Visual Basic 支持。

readonly structs 从 C# 7.2 开始可用。

还解释了here 为什么IDisposable ReleaseToken 结构没有被using 语句装箱。

Answer 2

如果我们考虑ThreadAbortException，这两个选项都是危险的。

1. 考虑 选项 1 和 ThreadAbortException 发生在 WaitAsync 和 try 之间。在这种情况下，将获取信号量锁但从未释放。最终这会导致僵局。

await _semaphore.WaitAsync();

// ThreadAbortException happens here

try
{
    // todo
}
finally
{
    _semaphore.Release();
}

1. 现在在选项2中，如果ThreadAbortException在获得锁之前发生，我们仍然会尝试释放其他人的锁，或者如果信号量是，我们会得到SemaphoreFullException未锁定。

try
{
    // ThreadAbortException happens here

    await _semaphore.WaitAsync();
    // todo
}
finally
{
    _semaphore.Release();
}

理论上，我们可以使用 选项 2 并跟踪是否实际获得了锁。为此，我们将把锁获取和跟踪逻辑放入finally 块中的另一个（内部）try-finally 语句中。原因是ThreadAbortException 不会中断finally 块的执行。所以我们会有这样的东西：

var isTaken = false;

try
{
    try
    {           
    }
    finally
    {
        await _semaphore.WaitAsync();
        isTaken = true;
    }

    // todo
}
finally
{
    if (isTaken)
    {
        _semaphore.Release();
    }
}

很遗憾，我们仍然不安全。问题是Thread.Abort 会锁定调用线程，直到中止线程离开受保护区域（我们场景中的内部finally 块）。这可能会导致僵局。为了避免无限或长时间运行的信号量等待，我们可以定期中断它并给ThreadAbortException 一个中断执行的机会。现在逻辑感觉安全了。

var isTaken = false;

try
{
    do
    {
        try
        {
        }
        finally
        {
            isTaken = await _semaphore.WaitAsync(TimeSpan.FromSeconds(1));
        }
    }
    while(!isTaken);

    // todo
}
finally
{
    if (isTaken)
    {
        _semaphore.Release();
    }
}

Answer 3

首选您的第一个选项，以避免在 Wait 调用抛出的情况下调用 release。不过，使用 c#8.0 我们可以编写一些东西，这样我们就不会在需要使用信号量的每个方法上出现太多难看的嵌套。

用法：

public async Task YourMethod() 
{
  using await _semaphore.LockAsync();
  // todo
} //the using statement will auto-release the semaphore

扩展方法如下：

using System;
using System.Threading;
using System.Threading.Tasks;

namespace YourNamespace
{
  public static class SemaphorSlimExtensions
  {
    public static IDisposable LockSync(this SemaphoreSlim semaphore)
    {
      if (semaphore == null)
        throw new ArgumentNullException(nameof(semaphore));

      var wrapper = new AutoReleaseSemaphoreWrapper(semaphore);
      semaphore.Wait();
      return wrapper;
    }

    public static async Task<IDisposable> LockAsync(this SemaphoreSlim semaphore)
    {
      if (semaphore == null)
        throw new ArgumentNullException(nameof(semaphore));

      var wrapper = new AutoReleaseSemaphoreWrapper(semaphore);
      await semaphore.WaitAsync();
      return wrapper;
    }
  }
}

还有 IDisposable 包装器：

using System;
using System.Threading;

namespace YourNamespace
{
  public class AutoReleaseSemaphoreWrapper : IDisposable
  {
    private readonly SemaphoreSlim _semaphore;

    public AutoReleaseSemaphoreWrapper(SemaphoreSlim semaphore )
    {
      _semaphore = semaphore;
    }

    public void Dispose()
    {
      try
      {
        _semaphore.Release();
      }
      catch { }
    }
  }
}

Answer 4

这是一个答案和一个问题的混合体。

来自一篇关于lock(){}实现的文章：

这里的问题是，如果编译器在监视器进入和 try-protected 区域之间生成一个无操作指令，那么运行时可能会在监视器进入之后但在尝试之前抛出线程中止异常。在那种情况下， finally 永远不会运行，所以锁泄漏，可能最终导致程序死锁。如果这在未优化和优化的构建中是不可能的，那就太好了。 (https://blogs.msdn.microsoft.com/ericlippert/2009/03/06/locks-and-exceptions-do-not-mix/)

当然，lock 不一样，但从这个注释我们可以得出结论，如果它还提供了一种方法来确定是否锁已成功获取（如文章中所述的Monitor.Enter）。但是，SemaphoreSlim 不提供这样的机制。

这篇关于using实现的文章说：

using (Font font1 = new Font("Arial", 10.0f)) 
{
    byte charset = font1.GdiCharSet;
}

转化为：

{
  Font font1 = new Font("Arial", 10.0f);
  try
  {
    byte charset = font1.GdiCharSet;
  }
  finally
  {
    if (font1 != null)
      ((IDisposable)font1).Dispose();
  }
}

如果可以在 Monitor.Enter() 和紧随其后的 try 之间生成 noop，那么转换后的 using 代码是否也会出现同样的问题？

也许AsyncSemaphore 的这个实现 https://github.com/Microsoft/vs-threading/blob/81db9bbc559e641c2b2baf2b811d959f0c0adf24/src/Microsoft.VisualStudio.Threading/AsyncSemaphore.cs

和SemaphoreSlim 的扩展名 https://github.com/StephenCleary/AsyncEx/blob/02341dbaf3df62e97c4bbaeb6d6606d345f9cda5/src/Nito.AsyncEx.Coordination/SemaphoreSlimExtensions.cs

也很有趣。

Answer 5

根据 MSDN，SemaphoreSlim.WaitAsync 可能会抛出：

1. ObjectDisposedException - 如果信号量已被释放

2. ArgumentOutOfRangeException - 如果您选择接受int 的重载并且它是负数（不包括-1）

在这两种情况下，SemaphoreSlim 都不会获得锁，这使得在finally 块中释放它变得不那么简单了。

需要注意的一点是，如果在第二个示例中对象被释放或为 null，finally 块将执行并触发另一个异常或调用 Release，它可能一开始还没有获得任何要释放的锁。

总而言之，为了与非异步锁保持一致并避免finally 块中的异常，我会选择前者

Answer 6

如果WaitAsync 中存在异常，则信号量未 被获取，因此Release 是不必要的，应该避免。您应该使用第一个 sn-p。

如果您担心在实际获取信号量时出现异常（除了NullReferenceException 之外不太可能），您可以尝试独立捕获它：

try
{
    await _semaphore.WaitAsync();
}
catch
{
    // handle
}

try
{
    // todo
}
finally
{
    _semaphore.Release();
}