posix 管道作为工作队列

Question

我见过的工作队列的正常实现涉及互斥锁和条件变量。

消费者：

A) Acquires Lock
B) While Queue empty
      Wait on Condition Variable (thus suspending thread and releasing lock)
C) Work object retrieved from queue
D) Lock is released
E) Do Work
F) GOTO A

制作人：

A) Acquires Lock
B) Work is added to queue
C) condition variable is signaled (potentially releasing worker)
D) Lock is released

我一直在浏览一些代码，并且看到了一个使用 POSIX 管道的实现（我以前没有见过这种技术）。

消费者：

A) Do select on pipe (thus suspending thread while no work)
B) Get Job from pipe
C) Do Work
D) GOTO A

制作人：

A) Write Job to pipe.

由于生产者和消费者是同一个应用程序中的线程（因此它们共享相同的地址空间，因此它们之间的指针是有效的）；作业作为工作对象（C++ 对象）的地址写入管道。因此，必须从管道中写入/读取的只是一个 8 字节地址。

我的问题是：

• 这是一种常见的技术吗（我是否已经避开了这个），有哪些优点/缺点？

我的好奇心被激起了，因为管道技术不涉及任何可见的锁定或信号（它可能隐藏在选择中）。所以我想知道这是否会更有效率？

编辑：

基于@Maxim Yegorushkin 回答中的 cmets。

实际上，此场景中的“生产者”参与了来自大量源的大量并行 IO。所以我怀疑原作者虽然很希望这个线程在任何情况下都不会被阻塞，但也不想在“Producer”线程中付出高昂的代价。

Answer 1

正如这里已经提到的，人们使用管道作为队列来避免阻塞非阻塞 I/O 线程中的条件变量（即在select/epoll 上处理多个套接字和块的线程） .如果 I/O 线程在条件变量或互斥体上阻塞，它就不能再进行非阻塞 I/O。

有人说写入管道涉及系统调用，并且当线程间事件量很高时可能会增加延迟。这仅适用于简单的基于管道的队列实现。

高级实现使用作业/事件的无锁链表，并且仅当将第一个作业添加到列表中时，才会写入管道以将目标 I/O 线程从阻塞 epoll 调用中唤醒（主要使用管道作为边缘触发的通知机制，但不用于传递指向作业/事件的指针）。因为唤醒一个线程需要几微秒，在此期间可能有更多的作业/事件发布到该线程的事件队列，但每个后续事件都不需要写入管道，直到稍后 I/O线程唤醒并消耗队列中的所有事件。此外，在较新的 Linux 内核中，可以使用更快的eventfd 代替管道来唤醒 I/O 线程。

Answer 2

我已经做到了。这是老式的，但它有效。

我这样做的原因是我需要唤醒同一个线程来完成任务或从另一个源读取输入，因此涉及到 select()。

Answer 3

这是因为select 及其结构。正如您在手册页中看到的那样

select() 和 pselect() 允许程序监视多个文件描述符，等待一个或多个文件描述符“准备好”用于某种 I/O 操作（例如，可能的输入）。如果可以在不阻塞的情况下执行相应的 I/O 操作（例如 read(2)），则认为文件描述符已准备就绪。

上面的关键是'等待一个或多个FD准备好'。那是两个线程之间的同步点。

Answer 4

我认为答案是管道技术的性能不如它涉及的系统调用那么好，系统调用相对昂贵。但这确实意味着所有棘手的锁定、睡眠和醒来都会为您处理好。

我自己都使用过，但管道仅用于偶尔的非性能关键应用程序。

编辑：我想我不妨提出标准建议，因为没有人提出任何明确权威的 cmets。

标准建议是：尝试两者并对其进行基准测试。这是找出哪个性能更好的一种真正方法...