tgoop.com/reverse13/663
Last Update:
Читал я тут блог автора перфбука
https://paulmck.livejournal.com/66175.html
Ничего разумного кроме lkmm и C++ mm для слабых mm не придумали.
Поэтому предлагается порассуждать об их отличиях
https://wg21.link/p0124r7
Основная разница в наличие более интересных барьеров и операций в линуксе, и наличию control, data, address dependency, что позволяет исключить OOTA (следствие этого некоторое различие между *_once и *_relaxed)
Но так как написание такого кода сложно, а его проверка статическими инструментами невозможна(?), автор приходит к выводу, что C++ mm (без relaxed) подходит для safe Rust куда больше (для тех кто забыл сейчас и safe и unsafe Rust "наследует" C++ mm, в том числе relaxed и связанные с ним костыли (OOTA)).
Лично на мой взгляд хотя вывод и достаточно разумный, мне близки идеи из статьи про golang mm, где автор предлагает выпилить acq/rel, оставить в safe расте только seq_cst звучит любопытно.
С другой стороны это приводит к проблеме, что на платформах с strong memory model (x86), мы получаем ценой чуть более простых гарантий менее эффективный код. И в отличие от relaxed статические инструменты легко работают с acq/rel семантикой.
То есть в правильном и эффективном коде станет больше unsafe и это печально.
Как вариант наверно можно подумать над тем чтобы позволить в safe разные порядки для load/store и для rmw операций?
В прочем это верно и для предложения автора, в основном из-за того, что есть несколько очень популярных паттернов, когда нам нужен relaxed, и мы знаем, что его использование корректно.
Но возможно такие паттерны стоит формализовать и обобщить некоторыми абстракциями?
Собственно про это автор пишет в
https://wg21.link/p2055r0
это самая полезная из приведенных ссылок с практической точки зрения.
https://paulmck.livejournal.com/63517.html
Так же он упоминает несколько других любопытных документов в контексте OOTA.
Напоминаю, что на практике его не существует.
Поэтому мне кажется что результаты https://wg21.link/p0422r0 весьма интересны.
Только компилятор, который умеет различать OOTA приводящий к проблемам от просто переупорядочиваний, может применять такие оптимизации, чтобы сделать OOTA возможным на практике.
А это значит, что если компилятор мог бы научится делать такие оптимизации, появился бы инструмент, чтобы проверять корректность такого кода, а это невозможно.
В конце же дается ссылка на любопытные исследования
https://www.cl.cam.ac.uk/~jp622/popl16-thinair
Но тут меня уже не хватило на чтение самих статьей, как-нибудь в другой раз.
BY Loser story
Share with your friend now:
tgoop.com/reverse13/663