Почему потоки никогда не включались как часть стандарта C ++?

Question

Почему потоки никогда не включались как часть стандарта C ++?Разве они не существовали, когда впервые был создан стандарт C ++?

Answer 1

Я думаю, что основными причинами являются

• , для определения поведения потоков в языке требуется много работы и понимания, чего никто не имел в то время
• никто не имел ни малейшего представления о том,хороший потоковый API, и не было ни одной существующей библиотеки, которая казалась бы достаточно хорошей, чтобы ее можно было использовать в качестве основы для дальнейшей работы.
• комитет по стандартизации был завален достаточным количеством другой работы (например, включением STL в стандартную библиотеку).)
• этот стандарт уже опоздал;потребовалось более десяти лет, чтобы появилась первая версия, с довольно большой задержкой из-за «изменений в последнюю минуту» (std::auto_ptr, STL), и я думаю, что главное чувство состояло в том, чтобы лучше что-то выпустить раньше, чем сохранитьожидание бесконечно отсроченного идеального стандарта;Я думаю, тогда большинство людей не думали, что для завершения следующей версии потребуется так много времени

После того, как стандарт был ратифицирован, члены рабочей группы библиотеки основали boost как испытательный стенддля библиотек, которые желательно иметь в std lib, но для которых не хватило времени сделать это для окончательной версии.Там была проделана большая работа, необходимая для добавления поддержки потоков в C ++ (а именно, создание хорошей библиотеки потоков).

Answer 2

Текущий стандарт с 1998 года. Существовали разные реализации потоков, и не было опыта использования потоков, который существует двенадцать лет спустя.Если бы в C ++ была стандартизованная библиотека потоков, она, вероятно, плохо работала бы с некоторыми распространенными реализациями потоков, и, возможно, ее было бы трудно адаптировать в будущем.

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

Answer 3

Потоки, безусловно, существовали, когда C ++ был стандартизирован в 1990-х годах. Тем не менее, Windows и Posix имеют очень разные API потоков. Проектирование библиотеки того качества, которое вы хотели бы получить из стандартной языковой библиотеки, предоставление всех необходимых потоковых примитивов и хорошее отображение на оба популярных API (и других) требовало больших усилий. Включение его в первоначальный стандарт потребовало бы либо отсрочки стандартизации, возможно, на годы, либо включения спецификации, которая могла бы иметь существенные недостатки.

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

Answer 4

Существует много работы, связанной с созданием класса потока, и C ++ 0x в значительной степени решил эту проблему путем добавления потоков, мьютекса и атомарных библиотек, но это заняло много работы у многих людей.

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

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

Технически недостаточно просто добавить API потока, в C ++ также отсутствовала единая модель памяти, т.е. как переменные взаимодействуют между потоками и как мы допускаем, чтобы широкий спектр моделей памяти был выражен в коде кратко (и качественно). Большинству из нас достаточно повезло работать с главным образом однопоточным программным обеспечением на базе x86, которое имеет очень щадящую модель памяти, но есть и другое оборудование, которое не столь простительно с точки зрения модели памяти и где потери производительности могут быть довольно суровыми.

Библиотека решает проблему модели памяти, предоставляя атомарные переменные с простыми значениями по умолчанию и явным контролем.

Библиотека предоставляет еще один ключевой элемент функциональности для переносимых потоков, предоставляя классы синхронизации.

Наконец, было добавлено, и если вы еще не прочитали историю на сайте рабочей группы, это интересно, но простой замены CreateThread, QueueUserWorkItem или вызова pthread в качестве объекта потока недостаточно. Необходимо продумать время жизни потока, управление состоянием и локальное хранилище потока.

На все это потребовалось много времени, чтобы понять все правильно, и, как уже упоминали другие, большая часть этого работала довольно долго, чтобы гарантировать, что основные проблемы были проработаны, и до того, как перейти к новому стандарту, это было согласованно.

Answer 5

Одна из проблем, с которой столкнулся комитет по стандартизации 12 лет назад, - это различия в параллельном оборудовании.Ключевой отличительной особенностью различных высокопроизводительных вычислительных архитектур является способ параллельного вычисления, и только одна из этих многих моделей действительно похожа на абстракцию потоков posix, SMP.

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

Это можно рассматривать как актуальное в современных терминах, сравнивая типичные вычислительные узлы белого ящика x86 / x64, которые обычно имеют до 4 сокетов, что переводит в 24 ядра с одной общей памятью на игровой ПК с несколькимиNVIDIA или AMD GPU.Оба способны поразительно вычислить пропускную способность, но чтобы получить максимальную отдачу от одного из них, требуется совсем другой стиль программирования.Фактически, различные рабочие нагрузки будут работать значительно лучше в одной архитектуре, чем в другой, в зависимости от точного характера конкретного алгоритма.

При этом, вероятно, 12 лет назад стандартный комитет не мог определить, как ему следует решать каждый из этих вопросов.Теперь, однако, ответ намного проще.C ++ не нацелен ни на что, кроме SMP-оборудования;они обслуживаются другими языками и цепочками инструментов, такими как OpenCL или VHDL.

Answer 6

Потоки - это вещь ОС, поэтому они не являются функцией языка программирования, а являются библиотеками, предоставляемыми системой.Например, потоки POSIX могут использоваться в C ++, но на самом деле не являются «частью» этого.

Answer 7

Потому что они зависят от ОС. И.Е. Unix / Linux / Macosx используют pthread API, Windows использует свой собственный API, и так далее, и так далее ...

Они могли бы быть включены в libstdc++, но я думаю, что нелегко включить все текущие и будущие функции потоков в общий API. Точно так же доступ к БД также не включен в libstdc++.

Answer 8

Поскольку авторы не хотели навязывать конкретное поведение исполнителям.