在同一个链中执行异步操作

The documentation for boost::asio::ssl::stream states the following regarding thread safety:

boost :: asio :: ssl :: stream的文档说明了有关线程安全的以下内容：

Thread Safety

线程安全

Distinct objects: Safe.

不同的对象：安全。
Shared objects: Unsafe. The application must also ensure that all asynchronous operations are performed within the same implicit or explicit strand.

共享对象：不安全。应用程序还必须确保所有异步操作都在同一个隐式或显式链中执行。

If i compare this to the documentation for the boost::asio::ip::tcp::socket type, then the statement about strands is not included.

如果我将此与boost :: asio :: ip :: tcp :: socket类型的文档进行比较，则不包括有关strands的语句。

Questions

问题

If access to the stream object is controlled by a mutex, making sure that only one thread operates on the ssl stream at a given time, what is the need for using an implicit/explicit strand?

如果对流对象的访问由互斥锁控制，确保在给定时间只有一个线程在ssl流上运行，那么使用隐式/显式链的需要是什么？

Also, what does "asynchronous operations" mean in this context? Is the document referring to calls to for example boost::asio::async_read/boost::asio::async_read, or to the handler callbacks I pass to these operations?

此外，“异步操作”在这种情况下意味着什么？文档是指调用例如boost :: asio :: async_read / boost :: asio :: async_read，还是调用我传递给这些操作的处理程序回调？

1 个解决方案

#1

If access to the stream object is controlled by a mutex, making sure that only one thread operates on the ssl stream at a given time, what is the need for using an implicit/explicit strand?

如果对流对象的访问由互斥锁控制，确保在给定时间只有一个线程在ssl流上运行，那么使用隐式/显式链的需要是什么？

There is no need then. The mutex makes the operations serialize as on a "logical strand". Asio's strands are merely a mechanism to achieve such serialization without the explicit synchronization code in case you have more than one service running the io_service

那时没有必要。互斥体使操作序列化为“逻辑链”。如果你有多个运行io_service的服务，Asio的链只是一种实现这种序列化的机制而没有显式的同步代码

Also, what does "asynchronous operations" mean in this context? Is the document referring to calls to for example boost::asio::async_read/boost::asio::async_read, or to the handler callbacks I pass to these operations?

此外，“异步操作”在这种情况下意味着什么？文档是指调用例如boost :: asio :: async_read / boost :: asio :: async_read，还是调用我传递给这些操作的处理程序回调？

Boost refers to it's implementation of those member functions/free functions indeed, because they operate on the service objects that aren't threadsafe. The completion handlers are your own concern: if you make them threadsafe then there is no more need for strands indeed. Be aware that you cannot start asynchronous operations directly from such "unserialized" completion handlers, which leads to code like:

Boost实际上是指它们对那些成员函数/*函数的实现，因为它们对非线程安全的服务对象进行操作。完成处理程序是你自己关注的问题：如果你使它们成为线程安全的话，那么就不再需要完成任务了。请注意，您无法直接从这些“未序列化”的完成处理程序启动异步操作，这会导致代码如下：

void completionhandler(error_code const& ec) { 
    if (!ec) { 
        io_service_.post([] { boost::asio::async_...(...); });
        // or: 
        strand_.post([] { boost::asio::async_...(...); });
    }
}

This leverages the fact that the strand and io_service objects are threadsafe.

这利用了strand和io_service对象是线程安全的事实。

#1