我正在查看 HTTP Server 3 Boost 网站上的示例。

请你们解释一下为什么我需要 strand 每个连接？如我所见，我们仅在读取事件的处理程序中调用 read_some 。所以基本上 read_some 调用是顺序的，因此不需要 strand (和 item 2 of 3rd paragraph 说同样的事情)。多线程环境的风险在哪里？

最佳答案

文档是正确的。用半双工协议(protocol)实现，如HTTP Server 3 , strand 不是必需的。调用链如下所示:

void connection::start()
{
  socket.async_receive_from(..., &handle_read);  ----.
}                                                    |
    .------------------------------------------------'
    |      .-----------------------------------------.
    V      V                                         |
void connection::handle_read(...)                    |
{                                                    |
  if (result)                                        |
    boost::asio::async_write(..., &handle_write); ---|--.
  else if (!result)                                  |  |
    boost::asio::async_write(..., &handle_write);  --|--|
  else                                               |  |
    socket_.async_read_some(..., &handle_read);  ----'  |
}                                                       |
    .---------------------------------------------------'
    |
    V
void handle_write(...)

如图所示，每个路径只启动一个异步事件。由于 socket_ 上的处理程序或操作不可能同时执行，因此据说它在隐式链中运行。

线程安全

虽然它在示例中并未显示为问题，但我想强调链和组合操作的一个重要细节，例如 boost::asio::async_write .在解释细节之前，让我们先介绍一下 Boost.Asio 的线程安全模型。对于大多数 Boost.Asio 对象，在一个对象上挂起多个异步操作是安全的；它只是指定对对象的并发调用是不安全的。在下图中，每一列代表一个线程，每一行代表一个线程在某一时刻正在做什么。

单个线程进行顺序调用而其他线程不进行是安全的:

 thread_1                             | thread_2
--------------------------------------+---------------------------------------
socket.async_receive(...);            | ...
socket.async_write_some(...);         | ...

It is safe for multiple threads to make calls, but not concurrently:

 thread_1                             | thread_2
--------------------------------------+---------------------------------------
socket.async_receive(...);            | ...
...                                   | socket.async_write_some(...);

However, it is not safe for multiple threads to make calls concurrently¹:

 thread_1                             | thread_2
--------------------------------------+---------------------------------------
socket.async_receive(...);            | socket.async_write_some(...);
...                                   | ...

Strands

To prevent concurrent invocations, handlers are often invoked from within strands. This is done by either:

• Wrapping the handler with strand.wrap. This will return a new handler, that will dispatch through the strand.
• Posting or dispatching directly through the strand.

Composed operations are unique in that intermediate calls to the stream are invoked within the handler's strand, if one is present, instead of the strand in which the composed operation is initiated. When compared to other operations, this presents an inversion of where the strand is specified. Here is some example code focusing on strand usage, that will demonstrate a socket that is read from via a non-composed operation, and concurrently written to with a composed operation.

void start()
{
  // Start read and write chains.  If multiple threads have called run on
  // the service, then they may be running concurrently.  To protect the
  // socket, use the strand.
  strand_.post(&read);
  strand_.post(&write);
}

// read always needs to be posted through the strand because it invokes a
// non-composed operation on the socket.
void read()
{
  // async_receive is initiated from within the strand.  The handler does
  // not affect the strand in which async_receive is executed.
  socket_.async_receive(read_buffer_, &handle_read);
}

// This is not running within a strand, as read did not wrap it.
void handle_read()
{
  // Need to post read into the strand, otherwise the async_receive would
  // not be safe.
  strand_.post(&read);
}

// The entry into the write loop needs to be posted through a strand.
// All intermediate handlers and the next iteration of the asynchronous write
// loop will be running in a strand due to the handler being wrapped.
void write()
{
  // async_write will make one or more calls to socket_.async_write_some.
  // All intermediate handlers (calls after the first), are executed
  // within the handler's context (strand_).
  boost::asio::async_write(socket_, write_buffer_,
                           strand_.wrap(&handle_write));
}

// This will be invoked from within the strand, as it was a wrapped
// handler in write().
void handle_write()
{
  // handler_write() is invoked within a strand, so write() does not
  // have to dispatched through the strand.
  write();
}

处理程序类型的重要性

此外，在组合操作中，Boost.Asio 使用 argument dependent lookup (ADL) 通过完成处理程序的链调用中间处理程序。因此，完成处理程序的类型具有适当的 asio_handler_invoke() 很重要。钩子(Hook)。如果类型删除发生在没有适当的 asio_handler_invoke() 钩子(Hook)的类型上，例如 boost::function 的返回类型是由 strand.wrap，则中间处理程序将在链外执行，只有完成处理程序将在链内执行。见 this详细回答。

在以下代码中，所有中间处理程序和完成处理程序都将在链中执行:

boost::asio::async_write(stream, buffer, strand.wrap(&handle_write));

在下面的代码中，只有完成处理程序会在链中执行。没有一个中间处理程序将在链中执行:

boost::function<void()> handler(strand.wrap(&handle_write));
boost::asio::async_write(stream, buffer, handler);

<子>1。 revision history记录此规则的异常情况。如果操作系统支持，同步读取、写入、接受和连接操作是线程安全的。为了完整起见，我将其包含在此处，但建议谨慎使用。

关于c++ - 为什么在使用 boost::asio 时每个连接都需要 strand？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/12794107/