Одно слово не описывает всю синхронизацию
Atomic read-modify-write относится к предусмотренной операции чтения и изменения определённого объекта. Это не универсальная гарантия порядка всех действий программы. Также атомарность не означает, что операция бесплатно выполняется над каждым адресом и мгновенно синхронизирует весь GPU. Поэтому поддержку atomic нельзя переписать как отсутствие гонок данных, максимальную пропускную способность или автоматическую согласованность любого обмена между CPU и устройством.
Материал посвящён аппаратно-программной семантике, не руководству написания кода. Здесь нет примеров для копирования в неизвестную платформу. Для точного вывода нужны API, тип, область и правила памяти. Общая архитектурная возможность не гарантирует одинаковые режимы каждого языка, а документ одного поколения не является паспортом всех мобильных GPU только по знакомому торговому названию семейства и установленному драйверу.
Read-modify-write
Обычная последовательность чтения, вычисления и записи не становится неделимой от красивого имени функции. Требуется предусмотренная операция и её условия. Но и такая операция имеет область. Нельзя считать её атомарной записью всего массива или файла. Для результата нужно знать объект, адресное пространство и поддерживаемый тип. Без этих сведений автор не может уверенно обещать корректность произвольного алгоритма и сохранение каждого промежуточного состояния приложения.
Также RMW не является только обычным присваиванием. Он относится к определённому взаимодействию со значением. Но точная функция зависит от API и формы операции. Нельзя по общему слову восстановить допустимые типы, ширину и результат. Поддержка целочисленного варианта не доказывает каждую аналогичную возможность для плавающей точки, а разрядность одного пути не задаёт универсальную ширину всех обращений памяти на выбранном GPU.
Область
Понятие scope помогает определить участников предусмотренного взаимодействия. Но его нельзя заменить количеством потоков на графике загрузки. Разные области и адресные пространства требуют документа. Если материал говорит об одной группе, нельзя автоматически расширять гарантию до всех устройств системы. Общая доступность памяти тоже не означает одинаковую семантику каждой операции, а знакомый адрес не превращает CPU и GPU в один абстрактный исполнитель без отдельных правил наблюдения.
Обратная ошибка — считать атомарность ненужной только потому, что задачи выполняются на одном GPU. Параллельное выполнение требует своих гарантий. Но статья не назначает конкретную схему исправления. Для рабочего кода нужен разработчик и применимая модель. Ограничение объяснения полезнее готового рецепта, который выглядит универсальным, но смешивает уровни, не учитывает тип объекта и может создать трудно воспроизводимые ошибки при изменении нагрузки или драйвера.
Порядок
Неделимость изменения и порядок остальных обращений являются связанными, но разными вопросами. Нельзя добавлять всем atomic-операциям одинаковые полные барьеры без определения. Также нельзя утверждать отсутствие любых правил. Нужно читать конкретную форму. Если источник не раскрывает семантику, вывод остаётся ограниченным, а автор не выбирает наиболее удобную гарантию по одному слову atomic или по успешному запуску примера на одной тестовой системе.
Согласованность и сохранность после потери питания тоже различаются. Атомарное обновление в рабочей памяти не обещает персистентность пользовательского проекта. Для хранения нужен другой путь. Нельзя переносить гарантии вычислительного API на файл или SSD. Также корректный результат нескольких запусков не доказывает отсутствие всех гонок, а неприятный артефакт картинки не является самостоятельным доказательством конкретного нарушения атомарности без исследования программы и условий возникновения.
Производительность
Нагрузка на один объект и работа с разными объектами могут иметь разное поведение. Но точные затраты нужно измерять. Поддержка операции не является обещанием постоянной скорости при любом соперничестве. Нельзя сравнивать GPU только по слову atomic и объявлять одинаковыми их реальные задачи. Для числа нужны операция, тип, область, распределение обращений и полезный результат, а не одна пиковая характеристика из другого сценария вычислений.
Также более быстрая схема не обязана иметь тот же порядок суммирования и численный результат. Корректность оценивают по требованиям задачи. Статья не обещает одинаковый ответ всех параллельных вычислений только по неделимым обновлениям. Для обзора сохраняют методику и данные, а неопределённые детали не превращают в надуманный универсальный штраф или преимущество производителя. Время и правильность остаются отдельными обязательными частями любой количественной оценки.
Конкурирующие обновления
Если много участников изменяют один счётчик, полезный вопрос — как обслуживается соперничество за этот объект. Если каждый работает со своим значением, вопрос уже другой. Одинаковое общее число операций не гарантирует одинаковое время двух схем. При этом адресная независимость сама по себе не раскрывает физическое размещение и все внутренние ограничения.
Для теста фиксируют распределение обращений. Иначе пиковый результат разнесённых объектов может быть ошибочно выдан за скорость одного общего счётчика приложения с совершенно иным характером взаимодействия.
Перед публикацией
Определения и модельная применимость требуют NEEDS_FACTCHECK_LATER. Главный вывод: atomic RMW, область, порядок и скорость различаются; неделимость одного объекта не синхронизирует всю программу, не гарантирует сохранность файла и не заменяет применимую модель памяти выбранного GPU и API.