Почему atomic double не реализован полностью

мой вопрос довольно прост. Почему не std::atomic<double> полностью реализован? Я знаю, что это связано с блокировкой переменной. Но я действительно не понимаю, почему это не должно быть возможно на двойном.

указано, что any тривиально копируемым тип можно использовать. И конечно двойная среди них. Таким образом, основные операции должны быть прекрасными (настройка, чтение и т. д.). Однако на целых числах возможен дополнительный набор операций (fetch_add, ++, +=, п.)

двойник очень мало отличается от этих типов. Это родной, trivally копировать и т. д. Почему стандарт не включал двойника с такими типами?

16
atomic c++ c++11 concurrency interlocked

2 ответов

std::atomic<double> поддерживается в том смысле, что вы можете создать его в своей программе, и он будет работать по правилам C++11. Вы можете выполнять нагрузки и магазины с ним и делать compare-exchange и тому подобное.

стандарт указывает, что арифметические операции (+, *, +=, &, etc.) предусмотрены только для атомов "интегральных типов", поэтому std::atomic<double> не будет иметь ни одной из этих операций.

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

(редактировать). В сторону,std::atomic<double> в VS2015RC без блокировки.

15

стандартные мандаты библиотеки std::atomic<T> где T-любое TriviallyCopyable тип. С double и TriviallyCopyable, std::atomic<double> должен компилироваться и работать отлично.

если это не так, у вас есть неисправный библиотека.

пример:http://goo.gl/QhaphY

Edit: поскольку комментарий уточняет вопрос:

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

  • fetch_add
  • fetch_sub
  • fetch_and
  • fetch_or
  • fetch_xor
  • оператор++
  • оператор--
  • операторы сравнения и назначения

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

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

8