使用std :: mutex作为boost :: asio管理的线程池

Question

不知怎的， 这个问题的后续行动。 我只是想知道在boost::asio:io_service函数中使用std::mutex可行？ 使用股线是不切实际的。 从我在boost参考中找到的我会说它没问题。 既然它说明了这一点

只能从当前调用io_service :: run（）的线程调用异步完成处理程序。

所以boost创建的其他线程不应该干扰。 我做对了吗？

Answer 1

正如其他人所说， std::mutex和其他锁定机制，可以在处理程序中使用。 但是，两者之间存在根本区别：

• 处理程序内的外部锁定机制用于保护资源免受竞争条件的影响。
• 一条strand用于消除处理程序之间的争用，从而消除处理程序之间的竞争条件。

如果整个处理程序由于与其他处理程序的潜在竞争条件而被同步，而不是线程池外部的线程，那么我想强调外部机制和boost::asio::strand之间的同步中的一个细微差别。 boost::asio::strand 。

请考虑以下情形：

• 使用Boost.Asio实现2个线程的线程池。
• 处理程序A和B将在同一个互斥锁上同步。
• 处理程序C不需要同步。
• 处理程序A ， B和C将发布到io_service 。

调用A和B 由于外部同步，线程池现在已耗尽，因为正在使用两个线程。 不幸的是，其中一个线程在资源上被阻塞，导致不需要同步的处理程序（例如C位于队列中。

如果在此方案中使用strand进行同步，则不会发生此饥饿实例。 一个strand维护自己的处理程序队列，并保证只有一个处理程序在io_service ，导致处理程序在被放入io_service之前被同步。 在该场景中，如果A和B被发布到strand ，则strand将A发布到io_service 。 这将导致A和C位于io_service ，允许C同时运行，而B保留在strand的队列中，等待A完成。

此外，还有一些用例可以同时使用这两种形式的同步。 例如，考虑资源与在线程池外部运行的线程共享的情况。 线程池内部和外部的线程仍然需要互斥锁。 但是，可以使用strand来消除线程池内部线程之间的互斥锁争用。

Answer 2

是的，在处理程序中使用std::mutex非常好。 毕竟，一个strand只是一个伪装成互斥的队列。

Answer 3

boost只是从它的角度调用回调。 这个回调与boost无关，所以boost不关心你在回调中做了什么。 因此，锁定（使用您想要的任何锁定库）是完全没问题的。

Answer 4

Mutex内部完成处理程序可以阻止线程执行。 在这种情况下，您需要比boost::thread::hardware_concurrency()更多的io_service线程来加载100％的CPU。 它增加了线程切换开销。