Может повысить.Блок Asio strand.dispatch()?

#c #multithreading #boost-asio

#c #многопоточность #boost-asio

Вопрос:

Я экспериментирую с Boost.Asio strand для сервера, который я пишу, и хотел бы прояснить несколько вещей.

Давайте предположим, что мы имеем SomeClass что-то вроде этого:

 void SomeClass::foo()
{
    strand_.dispatch(boost::bind(amp;SomeClass::bar, this));
}
  

Кроме того, strand имеет io_service вызов с несколькими потоками run() .

В документации на strand::dispatch() , которую я прочитал, это гарантирует, что обработчики, отправленные через цепочку, не будут выполняться одновременно, и если это выполнено, обработчик может выполняться в этой функции. Что решает, будет ли обработчик выполнен немедленно?

В этом случае с несколькими потоками, будет ли отправка блокироваться, если несколько потоков io_service вызываются SomeClass::foo одновременно? Т.е. блокируется для всех, кроме того, который выполняется. Если да, выполняются ли обработчики по порядку (в том порядке, в котором они были вызваны dispatch() )?

Ответ №1:

Логически, было бы невозможно выполнить эту гарантию без некоторой возможности (b) блокировки. Код для dispatch (подробно/impl/strand_service.hpp из 1.46.1) подтверждает это. Это хорошая особенность Boost, вы можете все увидеть. В документации здесь есть информация о порядке вызова обработчика, включая комментарий о том, что иногда гарантия упорядочения не предоставляется.

 template <typename Handler>
void strand_service::dispatch(strand_service::implementation_typeamp; impl,
    Handler handler)
{
  // If we are already in the strand then the handler can run immediately.
  if (call_stack<strand_impl>::contains(impl))
  {
    boost::asio::detail::fenced_block b;
    boost_asio_handler_invoke_helpers::invoke(handler, handler);
    return;
  }

  // Allocate and construct an operation to wrap the handler.
  typedef completion_handler<Handler> op;
  typename op::ptr p = { boost::addressof(handler),
    boost_asio_handler_alloc_helpers::allocate(
      sizeof(op), handler), 0 };
  p.p = new (p.v) op(handler);

  // If we are running inside the io_service, and no other handler is queued
  // or running, then the handler can run immediately.
  bool can_dispatch = call_stack<io_service_impl>::contains(amp;io_service_);
  impl->mutex_.lock();
  bool first = (  impl->count_ == 1);
  if (can_dispatch amp;amp; first)
  {
    // Immediate invocation is allowed.
    impl->mutex_.unlock();

    // Memory must be releaesed before any upcall is made.
    p.reset();

    // Indicate that this strand is executing on the current thread.
    call_stack<strand_impl>::context ctx(impl);

    // Ensure the next handler, if any, is scheduled on block exit.
    on_dispatch_exit on_exit = { amp;io_service_, impl };
    (void)on_exit;

    boost::asio::detail::fenced_block b;
    boost_asio_handler_invoke_helpers::invoke(handler, handler);
    return;
  }

  // Immediate invocation is not allowed, so enqueue for later.
  impl->queue_.push(p.p);
  impl->mutex_.unlock();
  p.v = p.p = 0;

  // The first handler to be enqueued is responsible for scheduling the
  // strand.
  if (first)
    io_service_.post_immediate_completion(impl);
}
  

Комментарии:

1. большое спасибо за ваш ответ. Глядя на источник, который вы включили, кажется, что до тех пор, пока в цепочке ничего не выполняется, а вызывающий поток является частью io_service, обработчик будет выполняться в вызывающем потоке. В других случаях будет поставлен в очередь и возвращен результат, в результате чего обработчик будет выполнен, когда цепочка будет свободна любым потоком в io_service. Это правильно?

2. Я думаю, это правильно. Немного иной подход можно получить, используя post вместо dispatch .

3. разве post здесь не только последний случай? Он всегда будет помещать обработчик в очередь strand для получения всякий раз, когда в strand ничего не выполняется. Или у этого также есть какой-то другой аспект того, как все работает?