В чем разница между атомарным и критическим в OpenMP?

Эффект на g_qCount такой же, но что сделано иначе.

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

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

Атомарная операция имеет гораздо меньшие накладные расходы. Там, где это возможно, он использует преимущества оборудования, обеспечивающего (скажем) операцию атомарного приращения; в этом случае нет необходимости в блокировке / разблокировке при входе / выходе из строки кода, он просто выполняет атомарное приращение, которое, по словам аппаратного обеспечения, вам нельзя мешать.

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

Конечно, в любом случае вы несете расходы на сериализацию.

В OpenMP все безымянные критические разделы являются взаимоисключающими.

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

Критический раздел:

• Обеспечивает сериализацию блоков кода.

• Может быть расширен для сериализации групп блоков при правильном использовании тега «name».

• помедленнее!

Атомарная операция:

• Намного быстрее!

• Обеспечивает только сериализацию определенной операции.

Самый быстрый способ не является ни критическим, ни атомарным. Примерно добавление с критическим сечением в 200 раз дороже простого добавления, атомарное добавление в 25 раз дороже простого добавления.

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

Ограничения atomic важны. Они должны быть подробно описаны в спецификациях OpenMP. MSDN предлагает краткую шпаргалку, поскольку Не удивлюсь, если это не изменится. (Visual Studio 2012 имеет реализацию OpenMP с марта 2002 г.) Процитируем MSDN:

Оператор выражения должен иметь одну из следующих форм:

x binop = expr

x++

++x

x--

--x

В предыдущих выражениях: x - это lvalue выражение скалярного типа. expr - это выражение скалярного типа, и оно не ссылается на объект, обозначенный x. binop не является перегруженным оператором и может быть одним из +, *, -, /, &, ^, |, << или >>.

Я рекомендую использовать atomic, когда это возможно, и именованные критические разделы в противном случае. Назвать их важно; таким образом вы избежите головной боли отладки.

Здесь уже отличные объяснения. Однако мы можем погрузиться немного глубже. Чтобы понять основную разницу между концепциями атомарной и критической секции в OpenMP, мы должны сначала понять концепцию блокировки. Давайте рассмотрим, почему нам нужно использовать блокировки.

Параллельная программа выполняется несколькими потоками. Детерминированные результаты будут достигнуты тогда и только тогда, когда мы выполним синхронизацию между этими потоками. Конечно, синхронизация между потоками не всегда требуется. Мы имеем в виду те случаи, когда необходима синхронизация.

Чтобы синхронизировать потоки в многопоточной программе, мы будем использовать блокировку. Когда требуется ограничить доступ только одним потоком за раз, в игру вступают блокировки. Реализация концепции блокировки может варьироваться от процессора к процессору. Давайте выясним, как может работать простая блокировка с алгоритмической точки зрения.

1. Define a variable called lock.
2. For each thread:
   2.1. Read the lock.
   2.2. If lock == 0, lock = 1 and goto 3    // Try to grab the lock
       Else goto 2.1    // Wait until the lock is released
3. Do something...
4. lock = 0    // Release the lock

Данный алгоритм может быть реализован на аппаратном языке следующим образом. Мы предположим, что это один процессор, и проанализируем поведение блокировок в нем. Для этого предположим, что один из следующих процессоров: MIPS, Alpha, ARM или Power.

try:    LW R1, lock
        BNEZ R1, try
        ADDI R1, R1, #1
        SW R1, lock

Эта программа вроде бы в порядке, но это не так. Приведенный выше код страдает от предыдущей проблемы; синхронизация. Давайте найдем проблему. Предположим, что начальное значение блокировки равно нулю. Если два потока запускают этот код, один может достичь SW R1, lock до того, как другой прочитает переменную lock. Таким образом, они оба думают, что блокировка свободна. Для решения этой проблемы предлагается другая инструкция, а не простые LW и SW. Это называется инструкцией чтение-изменение-запись. Это сложная инструкция (состоящая из подинструкций), которая гарантирует, что процедура получения блокировки выполняется только одним потоком за раз. Отличие команд Чтение-Изменение-Запись от простых инструкций Чтение и Запись состоит в том, что они используют другой способ Загрузка < / em> и Хранение. Он использует LL (Load Linked) для загрузки переменной блокировки и SC (Store Conditional) для записи в переменную блокировки. Дополнительный регистр ссылок используется, чтобы гарантировать, что процедура получения блокировки выполняется одним потоком. Алгоритм представлен ниже.

1. Define a variable called lock.
2. For each thread:
   2.1. Read the lock and put the address of lock variable inside the Link Register.
   2.2. If (lock == 0) and (&lock == Link Register), lock = 1 and reset the Link Register then goto 3    // Try to grab the lock
       Else goto 2.1    // Wait until the lock is released
3. Do something...
4. lock = 0    // Release the lock