Как сделать так, чтобы сопрограмма всегда работала в одном потоке?

Я хочу принять соединение в нити-0, а затем отправить этот сокет в один из других потоков (1 — 31) для балансировки нагрузки, и я хочу, чтобы все остальные операции с этим сокетом были в том же потоке, используя сопрограмму — для избегать переключения между потокамиг.

  • Я хочу выполнить асинхронный обратный вызов в разных потоках для балансировки нагрузки с помощью io_service+work+vector<boost::thread>,

  • Но в то же время я хочу выполнить все другие операции с этим сокетом, используя сопрограмму только в том же потоке — без балансировки нагрузки и с быстрым переключением контекста.

Если я использую boost.coroutine1 с помощью boost::asio::spawn() тогда может ли сопрограмма выполняться попеременно на разных потоках?

И если это возможно, то как сделать так, чтобы обратный вызов сопрограммы всегда выполнялся в том же потоке, из которого была вызвана асинхронная операция, даже если io_service связаны много потоков (пул потоков)?

    for (size_t i = 0; i < thread_num_executors; ++i)
thr_grp_executors.emplace_back(
boost::bind(&boost::asio::io_service::run, &io_service));

Как известно, переключение между сопрограммами происходит очень быстро, оно занимает около 10-12 нс на x86_64: http://www.boost.org/doc/libs/1_64_0/libs/coroutine/doc/html/coroutine/performance.html

Но это верно только в том случае, если переключение сопрограмм происходит в одном потоке. Потому что переключение потоков заняло более 100 нс.

Тогда как мне сделать так, чтобы сопрограмма всегда работала в одном потоке?

0

Решение

Если io_service связан со многими потоками, то нет способа заставить работу отображаться в одном и том же «физическом потоке» (так, логическом ядре).

Помимо этого, вы можете контролировать «логические потоки», порождая коро на нити.

Если вам необходимо иметь привязку к потоку, я не думаю, что есть лучший способ, чем запустить io_service в одном потоке, возможно, дублируя вместо этого io_service для каждого потока.

Все это может быть улучшено благодаря более обобщенному предложению Executors, и я считаю, что у Криса Колхоффа есть репо предварительного просмотра этого на его github. Вы можете посмотреть.

1

Другие решения

Других решений пока нет …