2014-11-19 4 views
12

Я читаю http://olk.github.io/libs/fiber/doc/html/ Мне кажется, что с Boost.Fiber C++ приближается к способности Erlang иметь тысячи «процессов», также известных как «зеленые процессы [threads]» http://en.wikipedia.org/wiki/Green_threads.С Boost.Fiber делает C++ на один шаг ближе к процессу/потокам стиля Erlang?

Мой вопрос: есть Boost.Fiber готов к производству, есть C++ альтернативы, которые имеют лучшую документацию и примеры? Кто-то упомянул легкие потоки, но я не могу найти ссылку на него. Один последний вопрос: почему стандарт C++ не включает Fibers?

Причина, по которой меня это интересует, заключается в том, что у меня есть обновления в реальном времени, когда изменение стоимости может воздействовать (порождать) сотни/тысячи небольших, но смущающих параллельных вычислений. Модель потока C++ работает не очень хорошо, imo. Пожалуйста, нет GPU, поскольку в настоящее время требуется слишком много времени для передачи информации на GPU и с него.

Я понимаю, что Эрланг гораздо больше, чем это, поэтому, пожалуйста, не просвещайте меня на Erlang vs C++ в общем случае.

+0

Действительно, это проблема с планированием и переключением контекста: http://www.linuxplumbersconf.org/2013/ocw//system/presentations/1653/original/LPC%20-%20User%20Threading.pdf – Ivan

ответ

13

Boost.Fiber был рассмотрен сообществом Boost в январе 2014 года, и было обнаружено, что ему нужна дополнительная дополнительная работа. Просмотрите результаты обзора сообщества по адресу http://lists.boost.org/boost-announce/2014/01/0393.php.

C++ 17 также использует WinRT, как модель потоковой передачи M: N, основанная на возобновляемых функциях с использованием предлагаемого ключевого слова ожидания. Microsoft внедрила поддержку в своем компиляторе, и помимо трюков для выделения магии памяти для фьючерсов это выглядит очень многообещающе. Соответствующий N-документ - N4134 (http://www.open-std.org/Jtc1/sc22/wg21/docs/papers/2014/n4134.pdf), и, как вы увидите, в случае его принятия эта формулировка возобновляемых функций действительно обеспечит масштабируемость типа Erlang, даже если синтаксис немного туповат (эй, это C++, когда его синтаксис всегда прост !).

Конечно, если вам требуется переносное решение, либо отправляйте маршрут без стекирования с ASIO (осторожно: он хрупкий), либо мелкозернистые обработчики ASIO с нитями ASIO, используя экземпляр класса в качестве вашего состояния выполнения, то же самое, или использовать Boost.Fiber в любом случае. Если вам нужно только Windows, я бы продвигаться вперед с фирменными расширениями Microsoft, сам, они сильно в отличие от них отказаться, если они не откажутся WinRT :)

Edit: Автор Boost.Fiber говорит мне, что по состоянию на январь 2015 рекомендуемые изменения в обзоре сообщества завершены, и кроме совершенствования документации Fiber считается готовым для включения в официальный Boost. Если это действительно так, то Fiber, вероятно, является лучшим решением, прежде чем официальная поддержка языка C++ 17 для окончательных возобновляемых функций появится в компиляторах.

+0

Спасибо. Это действительно полезно и интересно. Одна вещь, которую я заметил, это то, что сначала C++ 14/17 должен сначала реализовать понятие параллелизма, чтобы реализовать эти понятия. Так std :: await имеет смысл без std :: thread или std :: threadpool? – Ivan

+0

@Ivan: Вы в значительной степени поразили гвоздь на голове о комитете, определяющем, какую модель параллелизма использовать. Я бы сказал, что в настоящее время они разделены на это: с Hartmut (через HPX) и Microsoft через WinRT, используя модель потоков M: N, где M - это потоки ядра, а N - сопрограммы. Кроме того, только потому, что группа изучения параллелизма имеет одно мнение, это не означает, что они обязательно убедят комитет, хотя, если скажем, clang и MSVC реализуют экспериментальную поддержку компилятора, я бы сказал, что это запечатало бы обсуждение. –

+0

@Ivan: Относительно ожидания (не std :: wait, wait будет ключевым словом), требующим std :: thread, текущий план состоит в том, что существует концепция будущего и потока (помните, что понятия находятся на C++ 17), и если тип объявляет себя как реализующий концепцию, тогда теоретически компилятор примет это. Поэтому boost :: thread должен работать с ожиданием так же хорошо, как std :: thread, аналогичный для boost :: future vs std :: future. –