#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 ничего не выполняется. Или у этого также есть какой-то другой аспект того, как все работает?