Хотя Boost.Atomic стремится максимально точно реализовать атомные операции с C++11, есть несколько ограничений, которые нельзя снять без поддержки компилятора:
Использование не-POD-классов в качестве параметра шаблона для атомный<T> приводит к неопределенному поведению: Это означает, что любой класс, содержащий конструктор, деструктор, виртуальные методы или спецификации контроля доступа, не является обоснованным аргументом в C++98. C++11 немного смягчает это, позволяя «тривиальным» классам содержать только пустые конструкторы. Совет : Используйте только типы POD.
Компиляторы C++98 могут трансформировать вычислительную зависимость в зависимость от управления: Крайне важно, что memory_order_consume влияет только на вычислительно-зависимые операции, но в целом ничто не мешает компилятору трансформировать вычислительную зависимость в зависимость от управления. Компилятор C++11 будет запрещен для такого преобразования. Совет: Используйте memory_order_consume только в сочетании со значениями указателей, так как компилятор не может спекулировать и преобразовывать их в зависимости управления.
Защитные операции обеспечивают «слишком сильный» порядок компилятора : Семантически memory_order_acquire/memory_order_consume и memory_order_release необходимо сдерживать переупорядочение операций памяти только в одном направлении. Поскольку нет возможности выразить это ограничение компилятору, они действуют как «полные барьеры компилятора» в этой реализации. В угловых случаях это может привести к менее эффективному коду, чем компилятор C++11.
Нет межпроцессного запаса : с использованием атомный> в общей памяти работает только правильно, если атомный<свободный()==истинный.
Статья Limitations раздела The Boost C++ Libraries BoostBook Documentation Subset Chapter 6. Boost.Atomic может быть полезна для разработчиков на c++ и boost.
