Достаточно ли одного флага для работы Mutex

Краткий ответ: НЕТ, одного флага недостаточно.

Вопреки интуитивному представлению, простой булевый флаг или целочисленный счётчик не являются адекватной заменой sync.Mutex в Go для полноценной реализации взаимного исключения в конкурентной среде. Причина кроется в фундаментальных проблемах атомарности, видимости изменений между потоками (goroutine) и отсутствии гарантий синхронизации памяти.

Давайте разберём, почему флаг недостаточен, и что делает Mutex полноценным.

Почему простой флаг не работает

Предположим, мы пытаемсь защитить критическую секцию вот так:

var flag bool

func unsafeIncrement(counter *int) {
    for flag { // Ждём, пока флаг сброшен
    }
    flag = true // Поднимаем флаг

    // Критическая секция
    *counter++

    flag = false // Сбрасываем флаг
}

Проблемы такого подхода:

1. Состояние гонки (Race Condition): Две горутины могут одновременно прочитать flag == false, обе решат, что могут войти в секцию, и обе установят флаг в true. Это нарушает mutual exclusion.

2. Отсутствие атомарности операции "проверить-и-установить" (Test-and-Set): Между проверкой for flag и установкой flag = true может вклиниться другая горутина. Решение — использовать атомарные операции, например, sync/atomic:

   import "sync/atomic"
   
   var flag int32
   
   func slightlyBetterIncrement(counter *int) {
       for !atomic.CompareAndSwapInt32(&flag, 0, 1) {
           // Ждём
       }
       // Критическая секция
       *counter++
       atomic.StoreInt32(&flag, 0)
   }
   

   Но даже это не полноценное решение!

3. Проблема "активного ожидания" (Busy Waiting): Цикл for !atomic.CompareAndSwapInt32 постоянно потребляет процессорное время, даже если ресурс занят. Это крайне неэффективно.

4. Отсутствие очереди и гарантий справедливости: При высокой конкуренции одни горутины могут "жадничать", постоянно захватывая мьютекс, в то время как другие могут ждать очень долго (голодание, starvation).

5. Сложность с синхронизацией памяти (Memory Barrier/Fence): Даже после установки флага через атомарную операцию, компилятор или процессор могут переупорядочить инструкции внутри критической секции относительно операций с флагом, что может привести к неожиданному поведению. Нужны барьеры памяти.

Что предоставляет sync.Mutex

sync.Mutex в Go решает все вышеперечисленные проблемы:

• Атомарность захвата и освобождения: Внутренняя реализация использует низкоуровневые атомарные операции и системные вызовы.
• Эффективное ожидание: При неудачной попытке захвата горутина не "крутится" в цикле, а блокируется, отдавая процессорное время другим горутинам. Это реализовано через runtime scheduler и примитивы операционной системы (например, futex в Linux).
• Очередь ожидания: Внутренняя структура Mutex поддерживает очередь ждущих горутин, что помогает бороться с голоданием.
• Синхронизация памяти: Операции Lock() и Unlock() обеспечивают необходимые барьеры памяти. Любые записи в память, сделанные до Unlock(), гарантированно будут видны любой другой горутине после её успешного Lock().
• Дополнительные возможности:
  • TryLock() (с Go 1.18) для неблокирующей попытки захвата.
  • Возможность проверки, находится ли мьютекс в вырожденном состоянии (залоченный, но не ожидающий горутин) для отладки взаимоблокировок (deadlocks).

Пример корректного использования Mutex

import (
    "fmt"
    "sync"
)

type SafeCounter struct {
    mu sync.Mutex
    value int
}

func (c *SafeCounter) Increment() {
    c.mu.Lock()
    defer c.mu.Unlock() // Гарантированное освобождение, даже при panic
    c.value++
}

func main() {
    counter := &SafeCounter{}
    var wg sync.WaitGroup

    for i := 0; i < 1000; i++ {
        wg.Add(1)
        go func() {
            defer wg.Done()
            counter.Increment()
        }()
    }
    wg.Wait()
    fmt.Println(counter.value) // Гарантированно выведет 1000
}

Вывод

Таким образом, sync.Mutex — это сложный примитив синхронизации, который не эквивалентен простому флагу. Он обеспечивает:

1. Взаимное исключение.
2. Эффективное блокирование вместо активного ожидания.
3. Справедливость (в определённой степени).
4. Корректную синхронизацию памяти.

Использовать один флаг (даже атомарный) для защиты критической секции категорически не рекомендуется в реальных приложениях, кроме, возможно, простейших учебных примеров или случаев с очень специфичными и доказанными требованиями к производительности, где разработчик готов взять на себя все риски и сложности ручной реализации. sync.Mutex является стандартным, проверенным и безопасным решением.