Гарантирует ли Mutex порядок получения доступа на чтение или запись?

Краткий ответ

Нет, мьютекс в Go (да и в большинстве языков) НЕ гарантирует никакого порядка (FIFO, LIFO или иного) при предоставлении доступа. Он обеспечивает только базовые свойства взаимного исключения (mutual exclusion) и видимости изменений, но очередность разблокировки горутин, ожидающих блокировку, определяется планировщиком Go и реализацией рантайма.

Подробное объяснение

Основная задача мьютекса

Мьютекс (sync.Mutex) — это примитив синхронизации, главная цель которого:

1. Исключительный доступ: гарантировать, что в любой момент времени только одна горутина может выполнять критическую секцию кода, защищенную этим мьютексом.
2. Синхронизация памяти: гарантировать, что изменения в памяти, сделанные в критической секции, будут видимы следующей горутине, которая получит блокировку.

Порядок, в котором разблокированные горутины получают мьютекс, явно не определен спецификацией языка Go. Это сделано преднамеренно, чтобы предоставить максимальную гибкость реализациям рантайма для оптимизации производительности.

Почему порядка нет?

С точки зрения планировщика Go, горутины, ожидающие на мьютексе, находятся в состоянии ожидания (blocked). Когда текущий владелец мьютекса вызывает Unlock(), планировщик может разбудить одну или несколько ожидающих горутин. Какая именно из них будет следующей — это внутренняя деталь реализации, которая может зависеть от:

• Версии Go-компилятора и рантайма.
• Количества потоков ОС (GOMAXPROCS).
• Текущей нагрузки системы и состояния очередей планировщика.
• Случайных факторов (например, при использовании "голодного" режима).

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

Практическая демонстрация

Рассмотрим код, который наглядно показывает отсутствие гарантированного порядка:

package main

import (
    "fmt"
    "sync"
    "time"
)

func main() {
    var mu sync.Mutex
    var wg sync.WaitGroup

    // Запускаем 5 горутин, которые будут ждать мьютекс
    for i := 1; i <= 5; i++ {
        id := i
        wg.Add(1)
        go func() {
            defer wg.Done()
            fmt.Printf("Горутина %d: начинаю ожидание\n", id)

            mu.Lock() // Все горутины заблокируются здесь
            // Критическая секция
            fmt.Printf("Горутина %d: получила блокировку\n", id)
            time.Sleep(10 * time.Millisecond) // Симулируем работу
            mu.Unlock()
        }()
    }

    // Даем всем горутинам время встать в очередь
    time.Sleep(100 * time.Millisecond)

    // Первоначальная блокировка, которую захватят горутины
    mu.Lock()
    fmt.Println("\nОсновная горутина: отпускаю мьютекс...")
    mu.Unlock()

    wg.Wait()
}

При многократном запуске вы будете получать разные последовательности вывода после строки "отпускаю мьютекс". Например:

Запуск 1: 1, 3, 5, 2, 4
Запуск 2: 5, 2, 4, 1, 3
Запуск 3: 2, 1, 4, 5, 3

Что делать, если порядок важен?

Если логика вашей программы требует строгого упорядочивания доступа (например, обработка задач в порядке их поступления), необходимо использовать другие механизмы синхронизации:

1. Каналы (Channels): Являются идиоматичным способом для организации упорядоченной передачи данных и синхронизации в Go. Принцип "First In, First Out" (FIFO) для отправленных в канал значений гарантирован.

   // Гарантированный порядок обработки задач
   tasks := make(chan Task, 100)
   // Горутина-воркер будет получать tasks строго в порядке отправки
   go func() {
       for task := range tasks {
           process(task)
       }
   }()
   

2. Семафоры или условные переменные с очередью: В Go для сложных сценариев можно использовать комбинацию мьютекса, каналов или пакет sync.Cond (хотя последний требует аккуратного использования). Например, можно поддерживать собственную очередь идентификаторов или задач.

Режим "голодания" (Starvation Mode)

В современных реализациях sync.Mutex (начиная с Go 1.9) присутствует адаптивный механизм, который может переключать мьютекс между нормальным и "голодным" режимами. В "голодном" режиме блокировка передается непосредственно горутине-ожидателю, которая ждет дольше всех, чтобы предотвратить длительное голодание отдельных горутин. Это еще один фактор, влияющий на наблюдаемый порядок, но, опять же, не дающий строгих гарантий FIFO.

Вывод

• Мьютекс — не очередь. Его задача — безопасность, а не справедливость или порядок.
• Гарантированный порядок — это побочный эффект, а не контракт. На него нельзя полагаться при проектировании корректных параллельных программ.
• Для упорядоченной обработки используйте каналы. Они являются абстракцией более высокого уровня и предоставляют необходимые гарантии FIFO, идеально подходя для pipeline и рабочих очередей в Go.

Игнорирование этого принципа и неявная зависимость от наблюдаемого порядка разблокировки — классическая ошибка, которая приводит к трудноуловимым гейзенам-багам, проявляющимся только при высокой нагрузке или на другом железе.