Может ли Boost.Asio strand.dispatch () заблокировать? - PullRequest
4 голосов
/ 26 апреля 2011

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

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

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

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

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

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

1 Ответ

5 голосов
/ 27 апреля 2011

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

template <typename Handler>
void strand_service::dispatch(strand_service::implementation_type& 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(&io_service_);
  impl->mutex_.lock();
  bool first = (++impl->count_ == 1);
  if (can_dispatch && 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 = { &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);
}
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...