问题标签 [readwritelock]

我正在尝试使用 pthread API 在 Swift 中实现读/写锁，但遇到了一个奇怪的问题。

我的实现主要基于以下内容，并增加了尝试读锁的超时时间。

http://swiftweb.johnholdsworth.com/Deferred/html/ReadWriteLock.html

这是我的实现：

这是我的单元测试：

最后，我的单元测试的输出如下：

当然，测试失败是因为写锁没有及时释放。鉴于我的等待时间只有半秒（500 毫秒），为什么写锁执行和释放大约需要 570 毫秒？

我尝试过开启和关闭优化都无济于事。

我的印象nanosleep是高分辨率睡眠定时器，我希望这里的锁定超时分辨率至少为 5-10 毫秒。

任何人都可以在这里阐明一下吗？

我有一些使用 ReaderWriterLockSlim 的代码。当构建某个对象时，我会在其上获取写锁，并在稍后处理该对象时释放它。但是，由于这些调用的来源，我不能保证它们会在同一个线程上，这是 ReaderWriterLockSlim 的要求。

我相信一个合理的解决方案是在专用线程上运行对象的构造和处置，并让调用代码等待该任务完成（但保持线程处于活动状态）。看起来很乱，但如果不大规模重组我们的代码，我想不出另一种方法。

是否存在允许我在同一个线程上运行两个任务的现有 TaskScheduler 子类？

我当然愿意接受另一种这样做的范式。

如果我理解正确，如果我使用fair mode

读写锁没有优先级，所有锁都将按照其他线程的请求顺序获取。写请求接收后 - 如果

但我不确定非公平模式。正如在实践中以并发编写的那样，它是某种随机的。

但我并不完全理解这一点。

如果我理解正确的大多数使用 RWL 的利润，读者可以并行阅读。

但是让我们想象一下，我们有很多读取操作。假设几个线程不断持有读锁（单次读取不长，但两个邻居读取总是重叠）。并且有时会发生写操作。

写操作最终会被执行吗？

来自ReentrantLock javadoc：

公平模式
当构建为公平模式时，线程使用近似 到达顺序策略来竞争进入。当当前持有的锁被释放时，等待时间最长的单个写入线程将被分配写入锁，或者如果有一组读取线程等待的时间比所有等待写入线程的时间长，则将为该组分配读取锁。

如果持有写锁或存在等待写入线程，则尝试获取公平读锁（不可重入）的线程将阻塞。直到当前等待的最早的写线程获得并释放写锁之后，该线程才会获得读锁。当然，如果一个等待的写入者放弃它的等待，留下一个或多个读取线程作为队列中最长的等待者，并且没有写入锁，那么这些读取器将被分配读取锁。

除非读锁和写锁都空闲（这意味着没有等待线程），否则试图获取公平写锁（不可重入）的线程将阻塞。（请注意，非阻塞 ReentrantReadWriteLock.ReadLock.tryLock() 和 ReentrantReadWriteLock.WriteLock.tryLock() 方法不遵守此公平设置，如果可能，将获取锁，而不管等待线程。）

也许是我的英语有问题，但我在这个描述中看到了矛盾：
从第一段开始，我不明白大约到达订单政策的含义

1. 从第一段我了解到锁获取最旧的等待线程。如果最旧的线程 - 读取线程，那么它将是一组读取线程，其等待时间比等待时间最长的写入线程更长。
2. 从第二段我了解到，如果等待集中存在写锁，则不会获取读锁。

请澄清这个矛盾。

我正在开发一个项目，该项目需要使用特定的操作系统抽象，并且我需要使用它们的信号量和互斥锁来实现读写器锁。我目前有以下格式的设置：

在这个实现中，我需要使用这个 Unlock 方法来解锁写入器并释放所有读取器信号量槽，或者简单地释放读取器信号量槽，但是，我正在苦苦挣扎，因为我想不出一个实现，这将在所有工作案例。如何在给定的设置中完成这项工作？我知道这是可能的，因为 POSIX 能够在他们的实现中实现通用解锁方法，但我找不到任何迹象表明这是如何完成的，因此希望人们可以分享任何信息。

请注意，我不能使用 C++11 或其他操作系统原语。

在图书馆pthread.h是pthread_rwlock_t先进先出？

在下面的示例中，我们有多个线程。想象一下，每个线程都保证按顺序运行。

线程 1 释放锁后，谁获得了锁？是否保证线程 2 和 3 可以？还是可以给4？

同样，假设每个线程都保证按顺序运行，并且线程 1 在所有线程都尝试获取锁之前不会释放锁。

在休眠条件中使用 PESSIMISTIC_WRITE 作为 LockMode 作为 Select for update 查询的替代方案在性能上是否存在显着差异。

用例涉及以下几点：

1. 对状态、时间等多列中的值的限制
2. 在多列上排序
3. 仅选择第一行进行处理。

该处理由多个机器/线程同时完成。我目前正在使用休眠条件，这会导致多次锁定超时，从而导致所有其他查询阻塞。

与python whoosh IndexingError when interrupted不同，我没有中断任何提交，但IndexingError在创建新索引时发生：

错误：

作者应该在上下文范围内，所以我不确定为什么它是新创建的，但它被关闭了。如何解决新索引上的 IndexingError？

我正在做一个使用 Cassandra 的项目，但我在优化点上遇到了困难。考虑到读取操作在 Cassandra 上的负载非常重，我们希望更改数据库结构。

我在文档和论坛中搜索了答案，但找不到以下问题的明确答案。

目前我们将小批量写入 Cassandra，并且会连续读取。我们想让批次更大，所以我们可能每 10-15 分钟左右更换一半桌子。据我所知，Cassandra 仅在应用写入操作时锁定行。但这是真的吗？还是在写入时锁定整个表。而且（也许有点愚蠢的问题）你能在有写锁的情况下阅读吗？（因为当只有一个写锁的时候你仍然有机会阅读吗？）。

文档没有显示这种流程，而且这个问题似乎以前从未被问过。先谢谢了！

我遇到了 Writer 线程在没有锁的情况下被饿死的问题。请看下面的代码。如果我试图获取tryLock()用于读取锁的锁，写入器进程将变得饥饿并且永远无法写入。即使公平，编写程序也会完全饿死并且永远不会执行。相反，如果我只尝试，reader.readLock()那么编写器进程将能够获得锁。

如果我遗漏了什么，请告诉我，即使它设置为高优先级，编写器进程线程也永远不会获得锁并且会卡住等待锁。

谁能告诉我是否可以使用trylock()with ReadWriteLocks。