MacOSX: OSAtomic против OSAtomicBarrier - PullRequest
11 голосов
/ 13 марта 2010

Для функций здесь:

#include <libkern/OSAtomic.h>

есть версии OSAtomic и OSAtomicBarrier.

Однако в документации не показан пример кода для:

  1. Когда безопасно использовать только OSAtomic, без OSAtomicBarrier версии
  2. Когда OSAtomic будет небезопасным , но OSAtomicBarrier будет безопасным.

Может кто-нибудь дать объяснения + примеры кодов?

[Случайные разговоры о «вашем мнении» без реального кода бесполезны. Читатели: пожалуйста, проголосуйте за такие ответы; и энергично набирай ответы с реальным кодом.]

[код C / C ++ предпочтителен; Сборка тоже хорошо.]

Ответы [ 2 ]

7 голосов
/ 01 апреля 2010

На платформах Intel и однопроцессорных это не имеет значения.

В многопроцессорных системах PPC вы всегда должны использовать барьерные функции, если только атомарное хранилище не влияет на данные , отличные , чем атомная переменная.

Следующее не будет в порядке:

data_structure[y].data++;
OSAtomicIncrement32(y);

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

Однако, если вы используете атомарную переменную для какой-то цели, где она стоит одна, вы можете пропустить барьер:

// y is not used to access any other data
OSAtomicIncrement32(y);

Хорошо, если значение y не влияет на переменную какой-либо общей структуры данных.

По сути, это очистка кеша. Вы всегда можете безопасно использовать барьерные функции, но в некоторых случаях вы можете улучшить производительность, не используя барьерные функции, например, если y не используется относительно структуры данных. Вероятно, не так много случаев, когда вы можете использовать функции без барьера.

4 голосов
/ 28 августа 2013

Мне кажется, эта статья более подробно объясняет, что здесь происходит: http://www.mikeash.com/pyblog/friday-qa-2011-03-04-a-tour-of-osatomic.html. Довольно хорошее чтение.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...