时间戳

首页 > 解决方案 > 寻找适用于 async/await 的 Reader Writer Lock

.net - 寻找适用于 async/await 的 Reader Writer Lock

问题描述

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

这让我意识到我需要锁定原语。旧的锁定原语仅在您等待单个线程时才有效。有一个任务感知的 SemaphoreSlim，但我不明白它如何用于 Reader Writer 锁。

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

标签： .netmultitasking

解决方案

如果我可以使用 Microsoft 的某些东西，我不想使用 Stephen Cleary 的库。

我也是。

那么，这里有什么故事呢？

VS-Threading 库有一些历史。它最初是 VS-SDK 的一部分，用于（并且仅许可用于）VS 扩展。这并没有阻止人们找到它并使用他们自己的应用程序分发它，我多次建议不要这样做。这些天来，它被分拆成自己的项目，可在 NuGet 上获得，并获得 MIT 许可。所以我认为这些天使用它很好。但这就是历史，我认为历史就是它没有被广泛采用的原因。

是否有支持读写器锁定的 .NET 多任务原语？

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

我是否有理由避免使用 AsyncReaderWriterLock？

绝对地。我通常反对读/写锁。原因是很多开发人员认为“我的一些代码读，我的一些代码写，所以我需要一个 RWL”，而事实并非如此。还有额外的要求：读取的数量必须大大超过写入的数量，并且读取必须至少有可能压倒写入。如果没有满足这些额外的要求，那么一个简单的锁就可以了。对于异步代码尤其如此；在执行 I/O 时持有锁并不常见。

有没有人看到它工作的例子？

事实上，我没有，这有点好笑。但是查看源代码，我会说调用await ReadLockAsync/await WriteLockAsync然后处理结果值以释放锁。例如：

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

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

推荐阅读