Введение

Привет, Хабр! Эта статья посвящается важной теме работы в многопоточной среде. Для безопасной работы с одним ресурсом из разных горутин разработчик должен быть уверен в безопасности и обособленности действий, чтобы не создать ситуации, в которых "гонки данных" (data race) ломали бы важную логику и создавали коллизии данных.

В случаях, когда нужно обращаться к одному источнику из разных горутин в Go обычно используют sync/atomic или Mutex. Основная задача текущей статьи рассказать об их отличиях и о тех случаях, когда лучше применять atomic, чем sync.Mutex. Перед тем, как перейти к различиям, необходимо рассмотреть эти способы по ближе.

sync/atomic

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

Ниже рассматриваются некоторые методы из пакета sync/atomic для использования атомарных операций.

atomic.Load

Функция Load используется для атомарного чтения значений из переменной. Она позволяет безопасно получать значение, которое одновременно может измениться другими горутинами.

var isReady int32 = 0


// Атомарно читаем общие данные:
ready := atomic.LoadInt32(&isReady) // LoadInt32() - для чтения именно int32 типа
fmt.Printf("%v", ready)

Для разных типов в пакете sync/atomic существуют соответствующие функции. Например, LoadInt32() используется для атомарного чтения типа int32.

atomic.Store

Функция Store используется для атомарной записи значений.

var isReady int32 = 0

// Заносим данные в переменную по адресу в памяти:
atomic.StoreInt32(&isReady, 1)
fmt.Printf("%v", isReady)

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

atomic.Add

Функция Add необходима для атомарного сложения. Она очень удобна в случаях, когда нужно повысить значение данных (к примеру того же пресловутого счётчика).

var isReady int32 = 0

atomic.AddInt32(&isReady, 1)
fmt.Printf("%v", isReady)

atomic.CompareAndSwap

Функция CompareAndSwap является очень интересной. Она сравнивает значение из переменной с тем, которое вы указываете и заменяет на новое. Если значения равны, она заменяет на новое и возвращает true, если нет, то вернёт false, что означает, что замена не состоялась.

var isReady int32 = 0

result := atomic.CompareAndSwapInt32(&isReady, 1, 1)
fmt.Printf("%v", result)

Это были основные функции из пакета sync/atomic, но там также есть различные вариации функций для побитовых операций, таких как OR.

sync.Mutex

Это ещё один инструмент для синхронизации горутин. Он гарантирует, что в один и тот же момент времени только одна горутина может производить операции над данными, блокируя доступ из других горутин.
При базовом использовании в Mutex используются два метода:

Lock() - блокировка доступа.
Unlock() - разблокировка доступа.

Для начала рассмотрим пример кода без мьютексов (с гонкой данных):

var Counter int32 = 0

// Гонка данных без мьютекса:
func main() {
	
	wg := sync.WaitGroup{}
	wg.Add(2)

	go operator1(&wg)
	go operator2(&wg)
	
	wg.Wait()
	fmt.Printf("Final counter: %d", Counter)
}


func operator1(wg *sync.WaitGroup) {
	defer wg.Done()
	
	for i := 0; i < 5; i++  {
		Counter ++
		fmt.Println("\n", Counter)
	}
}


func operator2(wg *sync.WaitGroup) {
	
	defer wg.Done()
	for i := 0; i < 5; i++  {
		Counter ++
		fmt.Println("\n", Counter)
	}
}

При запуске go run -race . мы увидим такой вывод:

 1

 2

 3

 4

 5
==================
WARNING: DATA RACE
Read at 0x0000006262ac by goroutine 8:
  main.operator1()
      /home/maks/Projects/test1/main.go:28 +0xb6
  main.main.gowrap1()
      /home/maks/Projects/test1/main.go:16 +0x2e

Previous write at 0x0000006262ac by goroutine 9:
  main.operator2()
      /home/maks/Projects/test1/main.go:38 +0xcc
  main.main.gowrap2()
      /home/maks/Projects/test1/main.go:17 +0x2e

Goroutine 8 (running) created at:
  main.main()
      /home/maks/Projects/test1/main.go:16 +0xbe

Goroutine 9 (finished) created at:
  main.main()
      /home/maks/Projects/test1/main.go:17 +0x124
==================

 6

 7

 8

 9

 10
Final counter: 10Found 1 data race(s)
exit status 66

Необходимо исправить проблему, сделав работу безопасной с использованием мьютексов:


var Counter int32 = 0

func main() {
	
	wg := sync.WaitGroup{}
	wg.Add(2)
	var mutex sync.Mutex

	go operator1(&wg, &mutex)
	go operator2(&wg, &mutex)
	
	wg.Wait()
	fmt.Printf("Final counter: %d", Counter)
}


func operator1(wg *sync.WaitGroup, mutex *sync.Mutex) {
	defer wg.Done()
	
	for i := 0; i < 5; i++  {
		mutex.Lock()
		Counter ++
		fmt.Println("\n", Counter)
		mutex.Unlock()
	}
}


func operator2(wg *sync.WaitGroup, mutex *sync.Mutex) {
	
	defer wg.Done()
	for i := 0; i < 5; i++  {
		mutex.Lock()
		Counter ++
		fmt.Println("\n", Counter)
		mutex.Unlock()
	}
}

Но надо также учитывать, что sync.Mutex - это не просто флаг "свободен/занят". У него есть два режима работы, которые делают этот инструмент быстрым и справедливым для каждой горутины:

Нормальный режим: Работает по умолчанию. Как только мьютекс освободился, его захватить может любая из горутин, в том числе та, которая только что отработала. Это даёт большую производительность, но может привести к "голоданию".
Режим голодания: если горутина в очереди ждёт дольше 1 миллисекунды, мьютекс переключается в этот режим и здесь право захвата строго передаётся следующей в очереди горутине.

sync.RWMutex

Также стоит упомянуть про sync.RWMutex, который используется для сценариев, когда данные чаще читаются, чем изменяются. Здесь есть два метода RLock() и RUnlock(), которые используются для захвата мьютекса для чтения и освобождения соответственно. Множество горутин могут одновременно держать RLock(), если никто не пишет.

Различия sync/atomic и sync.Mutex

После введения основ по каждому инструменту, можно перейти к основной задаче этой статьи. На первый взгляд можно подумать, что оба инструмента выполняю одну и ту же роль - делают одновременный доступ из разных горутин безопасным. От части с этим согласиться можно, но на деле у них больше различий, чем сходств.

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

sync/atomic всегда быстрее sync.Mutex?

Это очень спорное заявление. Да, sync/atomic действительно может быть быстрее в случае, когда операция очень мала и её можно выразить одной атомарной операцией, но есть случаи, когда atomic действительно проигрывает Mutex. В бенчмарке ниже происходит сравнение atomic и Mutex на примере простой операции увеличения счётчика.

package main

import (
	"sync"
	"sync/atomic"
	"testing"
)

// Тест для Mutex
func BenchmarkMutex(b *testing.B) {
	var counter int64
	var mutex sync.Mutex

	b.RunParallel(func(pb *testing.PB) {
		for pb.Next() {
			mutex.Lock()
			counter++
			mutex.Unlock()
		}
	})
}

// Тест для atomic
func BenchmarkAtomic(b *testing.B) {
	var counter int64

	b.RunParallel(func(pb *testing.PB) {
		for pb.Next() {
			atomic.AddInt64(&counter, 1)
		}
	})
}

Результат:

maks@fedora ~/P/test1 [1]> go test -bench=. -cpu=1,2,4,8
goos: linux
goarch: amd64
pkg: test1
cpu: AMD Ryzen 5 7640HS w/ Radeon 760M Graphics     
BenchmarkMutex      	378627867	         3.171 ns/op
BenchmarkMutex-2    	195535148	         5.885 ns/op
BenchmarkMutex-4    	80525481	        13.01 ns/op
BenchmarkMutex-8    	46922386	        23.20 ns/op
BenchmarkAtomic     	753790170	         1.562 ns/op
BenchmarkAtomic-2   	193068660	         6.053 ns/op
BenchmarkAtomic-4   	247736799	         4.845 ns/op
BenchmarkAtomic-8   	190388100	         6.297 ns/op
PASS
ok  	test1	13.107s

Здесь видно как меняется производительность при разном уровне параллельного выполнения. Так при обычном BenchmarkMutexиBenchmarkAtomic результаты отличаются почти в два раза ( 3.171 ns/opвBenchmarkMutexпротив1.562 ns/opвBenchmarkAtomic). Но с ростом количества потоков ситуация проявляется ещё сильнее: в BenchmarkMutex-8значение23.20 ns/opпротивBenchmarkAtomic-8 со значением6.297 ns/op. Так как Здесь демонстрируется атомарная операция (увеличение счётчика). Её вполне можно уместить в одну инструкцию процессора.

При этом высокая конкуренция не делает atomic автоматически медленнее. Несколько ядер конкурируют за одну cahce line, содержащую счётчик и это даёт дополнительные накладные расходы на поддержание согласованности кэшей. Однако Mutex в этой ситуации тоже не является бесплатным. Он сам требует синхронизации между горутинами и добавляет стоимость блокировки и разблокировки.

По этой причине, при разработке лучше не ставить вопрос сравнения общей скорости работы atomic и Mutex, а смотреть за состоянием программы, за тем, какое количество одновременных горутин будет пытаться изменить один участок памяти и тем, какое количество операций и переменных за раз необходимо обезопасить.

Что и когда использовать?

Таким образом, использовать sync/atomic рентабельно, когда:

Вы делаете простой счётчик, работа с флагами.
У вас одна переменная, которая не зависит от других.
Вы понимаете порядок, в котором операции чтения и записи выполняются

Использовать sync.Mutex рентабельно, когда:

Хотите защитить больше одной переменной.
Есть инварианты между полями структуры.
Критическая секция содержит вызовы функций, I/O, аллокации
Вы не уверены, что вам лучше использовать

Заключение

Надеюсь эта статья была для вас полезна и помогла лучше понять особенности использования sync/atomic и sync.Mutex в Go. После прочтения этой статьи у вас должно было появиться понимание, что atomic - это не магический инструмент, который позволяет сделать из любой многопоточной реализации "ракету". Они больше подходят для тех случаев, когда необходимо обезопасить работу с отдельным значением, но по мере усложнения программы использование atomic может стать не выгодным. В конечном счёте, если вам необходимо защитить несколько связанных переменных или выполнить несколько операций, как единое целое, лучше использовать sync.Mutex. Подобный сценарий окажется более подходящим и понятным.

Когда atomic действительно быстрее Mutex