可升级读锁的优势？我想知道使用可升级读锁而不是执行以下步骤的优势是什么：读锁检查条件以查看我们是否需要写锁释放读锁获取写锁执行更新释放写锁与获取可升级读锁相反，执行上述步骤的一个明显缺点是在步骤3和步骤4之间有一个时间窗口，另一个线程可以持有写锁。除了这个优势，你有没有发现任何其他优势，你可以通过我上面提到的步骤获得可升级的读锁定能力？让我们考虑在没有单独的“可升级阅读器”的情况下使用询问器锁的不同方式。对于您的模式，正如您所指出的，在第3步和第4步之间存在竞争，其中另一个线程可以使用写入器锁。更重要的是，在第3步和第4步之间有一个线程可以获得写入器锁并更改我们在第2步中观察到的状态的步骤。因此，我们有四种选择，具体取决于它是如何发生的：我们坚持你的方法，因为它实际上是不可能（例如，在我们的应用程序中，给定的状态转换是单向的，因此一旦观察到它就是永久性的）。在这种情况下，我们完全可以重新设计，这样就根本不需要锁了。（单向转换适用于无锁技术）。我们就先用writerlock，因为我们在step2中观察到的state很可能会发生变化，用readerlock检查是浪费时间。让我们将您的步骤更改为：读取锁定检查条件以查看是否需要写入锁定释放读取锁定获取写入锁定如果更改则重新检查条件。执行更新释放写锁我们改为：在支持递归的锁上获取读锁。检查我们是否需要写锁。写锁（不释放读）。执行更新。释放写锁。释放读锁。不难看出为什么4对某些人更有吸引力，尽管更难看出它是如何使死锁更容易产生的。可悲的是，稍微用力一点就足以让很多人看到优势而不是劣势。各位没看出来，如果两个线程有??读锁，其中一个升级为写锁，就得等另一个线程释放读锁。但是，如果第二个线程升级到写锁而没有释放读锁，它就会在第一个线程上永远等待，而第一个线程会永远等待它。如上所述，哪种方法最好取决于状态同时发生变化的可能性（或者我想我们想要对其做出反应的速度）。即使是最后一种非释放升级方法也可以在可行的代码中占有一席之地，只要线程可以尝试升级其锁而不释放它。除了最后一个选项起作用的特殊情况外，其他选项之间的差异都与性能有关，而哪个选项的性能最高主要取决于重新检查状态的成本以及写入因更改而中止的可能性。与此同时。但是请注意，所有这些都涉及获取写入器锁，因此所有这些都具有阻塞所有读取线程的效果，即使写入确实中止了。可升级读锁给了我们一个中间地带，因为它们阻止写锁和其他可升级读锁，但它们不阻止读锁。它们可能更好，但不是可以升级为未提交写入的写入锁的读取锁。*如果决定不升级，对读取线程的影响为零。这意味着即使线程可能稍微决定不更改状态，读取线程也不会受到影响，并且性能提升肯定可以证明它的使用是合理的。*就此而言，“读写器”有点用词不当，我们可以使用ReaderWriterLockSlim保护一个int数组或对象，使用读锁以原子方式读写单个项目，并为需要的项目使用写锁读取整个数组读取时不更改部分的操作。在这种情况下，它是不需要排他锁的读操作，而使用共享锁的写操作就可以了。它还可以防止可能发生的死锁，因为不同的线程并发运行并且它们等待对方释放锁。以上就是C#学习教程：可升级readlock的优势？如果所有分享的内容对你有用，需要进一步了解C#学习教程，希望大家多多关注。本文收集自网络，不代表立场。如涉及侵权，请点击右侧联系管理员删除。如需转载请注明出处：
