Boost thread, Posix thread и STD thread, почему они предлагают разные характеристики?

Question

Насколько я знаю,

В информатике нить исполнения - это наименьшая последовательность запрограммированные инструкции, которые могут управляться независимо планировщик, который обычно является частью операционной системы. реализация потоков и процессов отличается между операционными системы, но в большинстве случаев поток является компонентом процесса. В одном процессе могут существовать несколько потоков, выполняющихся одновременно и совместного использования ресурсов, таких как память, в то время как разные процессы не поделитесь этими ресурсами. В частности, потоки разделяют процесс его исполняемый код и значения его переменных в любой момент времени. [ 1 ]

Когда я решил написать многопоточную программу на c ++, я столкнулся со многими вариантами, такими как boost thread, posix thread и std thread.

Простой поиск в Интернете показывает измерение производительности, сделанное boost.org веб-сайтом здесь .

Мой вопрос немного более прост и связан с производительностью.

В основном, почему они отличаются по производительности? Почему, например, поток типа A быстрее других? Они написаны большинством профессиональных программистов, работают под управлением мощных ОС, но предлагают разную производительность.

Что делает их быстрее или медленнее?

Answer 1

Документация Boost относится к библиотеке Fiber, которая на самом деле не является потоками. Создание того, что библиотека называет волокном (по сути, поток пользовательского пространства или сопрограмма, иногда также называемый зелеными потоками), не создает отдельную планируемую сущность на стороне ядра, поэтому она может быть намного более эффективной во время создания. Другие вещи могут быть менее эффективными, потому что операции ввода-вывода обязательно станут намного более сложными в этой модели (поскольку волокно, выполняющее ввод-вывод, не должно блокировать поток операционной системы, на котором он работает, если другие волокна могут работать там).

Обратите внимание, что некоторые из реализаций сопрограмм выходят за рамки концептуальных ограничений де-факто GNU / Linux ABI и других POSIX-подобных операционных систем, поэтому в лучшем случае их следует рассматривать как уродливые хаки.