Достаточно ли семантики приобретения / выпуска для реализации критических секций?

Question

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

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

Вот некоторый псевдокод, чтобы объяснить, что я имею в виду. Вот оригинальный код:

Thread 1:
    enter A // acquire semantics
    // ... some work within A
    leave A // release semantics

    enter B // acquire semantics
    // ... some work within B
    leave B // release semantics

Thread 2:
    enter B // acquire semantics
    // ... some work within B
    leave B // release semantics

    enter A // acquire semantics
    // ... some work within A
    leave A // release semantics

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

Thread 1:
    enter A // acquire semantics
    enter B // acquire semantics
    // ... some work within A
    // ... some work within B
    leave A // release semantics
    leave B // release semantics

Thread 2:
    enter B // acquire semantics
    enter A // acquire semantics
    // ... some work within B
    // ... some work within A
    leave B // release semantics
    leave A // release semantics

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

Так что не нужно, чтобы критические секции также предотвращали переупорядочение хранения / загрузки? То есть Разве они не нуждаются в последовательной последовательной семантике, а не просто получают / выпускают? Почему это не указано

Answer 1

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

1. Тема 1 получает A
2. Тема 2 получает B

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

1. Тема 2 получает B
2. Тема 1 получает A

но впоследствии поток 1 будет воспринимать себя как освобождающий А перед получением Б.