VE
(Или там SRW locks) если нужно с нераздельными ресурсами работать то доктор прописал использовать нормальные примитивы синхронизации а не самописные
Size: a a a
2020 December 24
VE
Проблема со списком мне не до конца ясна. Обычно в многопоточном программировании заморачиваются порядком в котором write из одного потока становятся видны в другом потоке. Те вы допустим инициализируете объект и потом добавляете его в список - в слабых моделях можно оказаться в ситуации где указатель на объект станет видим до того как другой поток (сидящий на другом ядре) увидит записи инициализации полей объекта - но синхронизация встроенными примитивами это предотвращает. На Интеле такой проблемы нет (если только компилятор не переупорядочит, сам процессор такого не делает).
RS
Если "но синхронизация встроенными примитивами это предотвращает" то действительно надо попробовать сделать синхронизацию встроенными средствами, возможно, это действительно решит проблему.
VE
Я сомневаюсь что у вас проблема именно в этом - если вы не на АРМе. Мой совет был бы выписать на бумажку операции которые делает один поток и которые делает другой поток в столбик и рассмотреть разные варианты их чередования. Это покажет проблему. Если бы у вас был бы не самописный язык а плюсы я бы просто рекомендовал засунуть в TSAN
EM
Rifat S
Спасибо, Роман за статьи. Почитаю. По поводу того, что Деккер не корректен н x86. Есть какой-нибудь алгоритм аналогичный Деккеру, который можно достаточно легко реализовать и который будет корректен на x86?
Обычный спинлок на CAS будет корректен без барьеров на x86 (но нужно использовать CAS, а вы вроде не хотите это делать).
Из экзотики, есть вот такой алгоритм https://en.m.wikipedia.org/wiki/Szyma%C5%84ski%27s_algorithm. Он вроде тоже не требует барьеров, но тут я не до конца уверен :)
Из экзотики, есть вот такой алгоритм https://en.m.wikipedia.org/wiki/Szyma%C5%84ski%27s_algorithm. Он вроде тоже не требует барьеров, но тут я не до конца уверен :)
AG
What about atomic values/types and CAS?
к касам всё равно ж нужны барьеры в слабой памяти
AT
к касам всё равно ж нужны барьеры в слабой памяти
Я про C11 думал. Там барьеры прямо в CAS не встроены?
AG
по моему нет, там надо дополнительно желаемый ордеринг прописывать
AG
но тут еще вопрос что считать C11, там же не одна модель
AG
насколько я понимаю это от того что нужно поддерживать как x86 который довольно строг, так и всякие армы которые послабее
AT
насколько я понимаю это от того что нужно поддерживать как x86 который довольно строг, так и всякие армы которые послабее
Это поддерживается как бы "автоматически" за счёт того, что на x86 уровень relaxed по факту не более relaxed, чем cst или как их там.
AG
так я и говорю что оно не только в х86 должно уметь гнать
DF
rmw операции всегда видят последнее значение в порядке модификации
AT
так я и говорю что оно не только в х86 должно уметь гнать
Так если корректно работает на relaxed, значит на x86 и подавно. 😊
DF
Если по с++ модели судить
AG
я короче это всё к тому что во всех формализациях C11 что я видел, касы всегда аннотированы двумя параметрами ордеринга
AG
один для успешного чтения, второй для фейла
AG
а там уже от архитектуры конкретной зависит будут там доп барьеры или нет
AG
типа такого
DF
Ага , полезно