.net - 寻找适用于 async/await 的读写锁

Question

我正在将旧应用程序移植到 .NET Core。我需要一个读写锁(很多读操作，偶尔写操作)。我的旧代码是大量多线程的，所以旧的 ReaderWriterLock 工作得很好。新代码是基于任务的，所以我尝试采用异步/等待模式。

这让我想到了锁定原语的需要。旧的锁定原语仅在您等待单个线程时才有效。有一个任务感知的 SemaphoreSlim，但我不知道如何将其用于读写器锁。

我找到了这个:AsyncReaderWriterLock ，但我找不到任何使用示例或似乎正在使用它的任何人。如果我可以使用 Microsoft 的东西，我不想使用 Stephen Cleary 的库。那么，这里的故事是什么？是否有支持读写器锁定的 .NET 多任务原语？我应该避免使用 AsyncReaderWriterLock 有什么理由吗？有没有人看到它起作用的例子？

Answer 1

I don't want to use Stephen Cleary's library if I can use something from Microsoft.

我也是。

So, what's the story here?

VS-Threading library有一点历史。它最初是 VS-SDK 的一部分，旨在用于(并且仅授权用于)VS 扩展。这并没有阻止人们找到它并用他们自己的应用程序分发它，我曾多次建议不要这样做。如今，它已独立成自己的项目，可在 NuGet 上使用，并获得 MIT 许可。所以我觉得这几天用着没问题。但这就是历史，我认为历史是它没有被广泛采用的原因。

Is there a .NET multi-tasking primitive that supports reader writer locking?

不作为框架的一部分(至少，现在还没有)。有 AsyncEx , VS-Threading , 和 roll-your-own .我不确定 VS-Threading 在 Microsoft 支持方面存在于何处 - 即，它是否由特定团队维护？我确实在最近的提交中看到了 Andrew Arnott 和 Sam Harwell，他们都是这个领域的天才，所以我想说现在掌握得很好。我只是不确定它是 Microsoft 项目的官方程度。

Is there a reason I should avoid using AsyncReaderWriterLock?

当然。我通常反对读者/作者锁。原因是很多开发人员认为“我的一些代码读取，一些代码写入，所以我需要一个 RWL”，但事实并非如此。还有其他要求:读取的数量必须远远超过写入的数量，并且读取的数量必须至少有压倒写入的数量。如果不满足这些附加要求，那么一个简单的锁就可以了。对于异步代码尤其如此；在进行 I/O 时持有锁并不常见。

Has anyone seen an example of it working?

实际上，我没有，这很有趣。但是看着 the source ，我会说调用 await ReadLockAsync/await WriteLockAsync 然后处理结果值以释放锁。例如:

using (var releaser = await arwl.ReadLockAsync())
{
  ... // code using await
}

AsyncEx 和 roll-your-own 方法具有相同的用法。