Почему стек не поддерживает многопоточность?

Отличный вопрос, который касается самых основ архитектуры процессоров и организации памяти. Важно сразу внести ясность: сам по себе стек (как структура данных «последним пришел — первым вышел», LIFO) может быть реализован с поддержкой многопоточности. Однако в контексте iOS/macOS разработки и низкоуровневого программирования, когда говорят «стек» (stack), почти всегда имеют в виду стек вызовов (call stack) потока. Вот его многопоточность действительно не поддерживает, и вот почему.

Архитектура стека вызовов потока

Каждый поток в операционной системе имеет свой собственный, уникальный и изолированный стек вызовов. Это фундаментальный принцип, заложенный в архитектуру современных ОС и процессоров.

// Упрощенно, поток можно представить так:
struct thread {
    void *stack_pointer;  // Указатель на вершину своего стека
    void *stack_base;      // Указатель на основание своего стека
    // ... другие регистры и состояние
};

Стек потока — это непрерывная область памяти, выделенная ОС при создании потока. Его основные цели:

• Хранение локальных переменных функций.
• Передача аргументов функциям (согласно соглашению о вызовах, calling convention).
• Сохранение адреса возврата из функции (куда прыгнуть после return).
• Сохранение контекста (значений регистров) при вызове новой функции.

Причины отсутствия прямой многопоточности

1. Аппаратная зависимость и регистр SP/ESP/RSP

Ключевую роль играет регистр указателя стека (Stack Pointer). В любой момент времени процессор «знает» о единственном текущем стеке, на который указывает этот регистр. При переключении контекста (смене потока) ОС обязана сохранить значение SP текущего потока в его структуре данных и загрузить в регистр SP значение, сохраненное для нового потока.

; Упрощенное переключение контекста
save_context_of_thread_A:
    PUSH all registers ; Сохраняем регистры в стек потока А
    MOV [thread_A_sp_backup], SP ; Сохраняем текущий SP для потока А

restore_context_of_thread_B:
    MOV SP, [thread_B_sp_backup] ; Восстанавливаем SP потока В!
    POP all registers  ; Восстанавливаем регистры из стека потока В
    RET                ; Продолжаем выполнение потока В

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

2. Локальность данных и предсказуемость

Стек потока — это автоматическая память. Его организация (кадры стека, stack frames) предполагает строгую вложенность вызовов и возвратов. Это позволяет:

• Эффективно использовать кэш процессора. Доступ к стеку очень быстрый, так как он обычно находится в «горячей» области кэша L1.
• Обеспечивать предсказуемость. Компилятор и ОС точно знают границы стека потока и могут вставлять защиту от переполнения (stack guards).

Если бы несколько потоков работали с одной областью стека, эта предсказуемость исчезла бы. Доступ к данным потребовал бы синхронизации (мьютексов, семафоров), что свело бы на нет главное преимущество стека — скорость.

3. Изоляция и безопасность

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

Как организовать обмен данными между потоками?

Поскольку стеки изолированы, для взаимодействия потоки используют общую память (heap).

class SharedData {
    private let queue = DispatchQueue(label: "com.example.syncQueue", attributes: .concurrent)
    private var _value: Int = 0

    var value: Int {
        get {
            return queue.sync { _value }
        }
        set {
            queue.async(flags: .barrier) { self._value = newValue }
        }
    }
}

// Поток 1 (имеет свой стек)
let data = SharedData()
data.value = 42 // Пишет в кучу (heap)

// Поток 2 (имеет свой стек!)
DispatchQueue.global().async {
    print(data.value) // Читает из кучи (heap)
}

• Локальные переменные (data в примере) живут в стеке своего потока. Сам объект SharedData и его свойства размещены в куче (heap).
• Для безопасного доступа из нескольких потоков используется синхронизация (в примере — GCD с барьером).

Итог

Стек вызовов потока не поддерживает многопоточность, потому что:

• Аппаратно привязан к одному регистру указателя стека (SP) на ядро процессора.
• Его архитектура предполагает строгую вложенность и изоляцию для предсказуемости и скорости.
• Изоляция стеков обеспечивает стабильность — ошибка в одном потоке не разрушает состояние других.
• Многопоточность реализуется через разделяемую кучу (heap) и механизмы синхронизации доступа к данным в ней, а не через общий стек.

Таким образом, отсутствие многопоточности у стека — не недостаток, а продуманная архитектурная особенность, обеспечивающая эффективность, надежность и саму возможность существования многопоточных программ.