0

我们可以在 Unices 系统中用于异步 I/O 警报的工具，例如 Linux 上的 epoll、BSD 系统上的 kqueue 和 Solaris /dev/poll 或 I/O 端口，所有这些都允许用户指定一个与用户想要接收 I/O 警报的文件描述符。

通常在这个指针中，用户指定一个指向一个结构的指针，该结构将抽象一个文件描述符（例如“Stream”结构，或类似的东西），并且每次打开一个新的文件描述符时，用户都会分配一个新的结构。

例如struct stream { int fd; int flags; callback_t on_read_fn; /* ... */ };

现在，我的问题是：如何安全地释放用户在多线程环境中分配的这个结构？

我问这个，因为 epoll/kqueue/etc 的性质：你通常有一个线程从内核“下载”一个事件向量，包含具有一些 I/O 准备的文件描述符，以及一个与之关联的用户指针文件描述符。

现在，让我们考虑一下我有 2 个线程：T1 下载这些事件并处理它们，例如调用stream->on_read_fn();等，T2 简单地运行用户代码、用户事件和类似的东西。

如果 T2 想要关闭一个文件描述符，只需执行此操作close(stream->fd);，T1 就不会再收到该 fd 的任何 I/O 警报，因此在stream那里释放结构是安全的。

但是，如果 T1 线程已经在它正在处理的事件向量中下载了相同的文件描述符，但它还没有处理那个文件描述符呢？

如果 T1 被安排在 T2 之前，它会没问题，但如果 T2 被安排在 T1 之前，它将关闭文件描述符并释放stream结构，因此线程 T1 在处理该文件描述符时将有一个用户关联指针，指向一个已经释放的结构！当然，这会严重崩溃。

我的观点是，如果线程 T1 为该特定文件描述符下载了一些 I/O 警报，T2永远不会知道，T2 也无法预测 T1 是否会下载一些 I/O 警报或根本不下载！

这非常棘手，它让我头晕目眩。有什么想法吗？在这种情况下，何时可以安全地释放用户指定的指针？

注意：我的一个朋友建议在调用之前从 epoll/kqueue 队列中删除文件描述符close(2)。没错，这就是我现在所做的，但这并不能解决问题，因为 T2 可以从 epoll/kqueue 队列中删除文件描述符，但这并不能保证该文件的 I/O 事件描述符尚未从内核“下载”，将很快由线程 T1 处理。

4

3 回答 3

1

我遇到了完全相同的问题，这就是为什么在新的 linux 内核提案中，有人（不记得名字）建议为 FD 实现 DISABLED 状态，这样如果它已被另一个线程释放，您可以跳过处理。

就个人而言，我从多线程 epool 调用转移到 FD 上的 epool() 单线程，然后将事件调度到多个线程。内部的对象本身被引用计数，然后由垃圾收集器收集。老实说，效果很好，并且对多线程 epool 解决方案没有明显的降级...

*已编辑*

此外，我研究了另一种从同一线程关闭 FD 的方法，而不是处理 epool，方法是创建一个受互斥锁保护的 std::set，并在需要关闭 FD 时由消费者线程填充。这也很有效。

于 2015-02-27T12:57:42.480 回答
1

我在我的程序中通过不释放结构解决了这个问题，而是将其标记为“死”并将其添加到列表中以便以后可以重用。这样，指针始终保持有效，尽管它可能已被重用。

于 2020-05-23T02:11:51.040 回答
0

我宁愿避免在 2 个线程之间共享相同的数据结构。

过去，使用“一次性”技巧，这在许多系统上似乎是可移植的。对于一次性行为，一旦事件发出信号，它会暂时从队列中“取出”，即不会通知其他线程任何 fd 变得可读或可写。

完成事件处理后，您需要将其添加回 epoll/kqueue（正如 Linux 文档所说，“重新武装” fd）。

  • 在 Linux 上：

    添加到 epoll ： epoll_ctl()/EPOLL_CTL_ADD ，标志 EPOLLET|EPOLLONESHOT

    重新武装：epoll_ctl()/EPOLL_CTL_MOD 使用相同的事件标志。

  • 在带有 kqueue 的 BSD/OSX 上

    添加到 kqueue：EV_SET(...EV_ADD|EV_ONESHOT...);

    重新武装：EV_SET(...EV_ADD|EV_ONESHOT...);

  • 在 Solaris 上

    只需使用 port_associate() 来添加和重新武装。

于 2015-03-06T01:53:00.007 回答