LINUX.ORG.RU

Мультитред, чтение меняющейся переменной без локов

 ,


0

4

Допустим, есть переменная, полностью обычная (просто char a; - для определённости пусть будет однобайтовая). Ещё до начала совместного к ней доступа она инициализируется либо нулём, либо не нулём. Если ноль - то дальше она не меняется. Если не ноль - то дальше в неё могут записываться другие ненулевые значения в произвольные моменты времени. Другой тред читает эту переменную, не утруждая себя межтредовой синхронизацией, но единственное что ему нужно - выяснить ноль в ней или нет. Как мне кажется, никаких проблем это создать не должно ни при каких обстоятельствах. Однако может быть я что-то упустил? И второй вопрос, отдельный: где формально написано что так можно?

★★★★★

Последнее исправление: firkax (всего исправлений: 2)
Ответ на: комментарий от JaM

Вот уже конкретика пошла. Такой код компилятору генерить и правда незачем, но вроде никто не запрещает. Кстати от такого плохого поведения теоретического вредоносного компилятора поможет volatile.

firkax ★★★★★
() автор топика
Ответ на: комментарий от asdpm

это нужно именно чтобы наоборот - не открывать документацию на процессор

И знаете во что это выливается? Даже в бОльшие усилия на якобы-универсальный код (проверить то вы всё равно сможете только на том железе и компиляторе что у вас), который зачастую медленней / хуже чем то что писалось под конкретную платформу. Я это называю «академическим программированием» и никогда не был сторонником такого подхода. Мне ехать, а не шашечки. Уверен, многие здесь мою точку зрения не разделяют.

bugfixer ★★★★★
()
Ответ на: комментарий от bugfixer

Плюс академического программирования в том, что правильно написанный код будет работать и сейчас и через десять лет. А заточенный под конкретную версию компилятора код может сломаться с обновлением версии компилятора. Когда ломается код, связанный с многопоточностью, это особенно неприятно.

Лично моё мнение - нужно писать код «академичный», в такой формулировке. При этом если есть какие-то существенные проблемы с производительностью, этот участок нужно переписывать на ассемблере, делая его альтернативной реализацией.

vbr ★★★★★
()
Ответ на: комментарий от vbr

что правильно написанный код будет работать и сейчас и через десять лет.

Вы чрезвычайно оптимистичны.

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

Он может сломаться по миллиону других причин даже будучи полностью standard-compliant. Обновление компилятора это big deal, очень big deal.

При этом если есть какие-то существенные проблемы с производительностью

Всё в этом мире относительно. Курочка по зёрнышку. Я не понимаю почему я должен платить сейчас (и усилиями и перформансом) за гипотетическую возможность покрыть платформу которой у меня может никогда и не будет. Вот когда такая платформа появится - вот тогда я и буду на неё внимательно смотреть, и подкручивать код где это необходимо, по дороге делая разумные и обоснованные компромисы.

bugfixer ★★★★★
()
Последнее исправление: bugfixer (всего исправлений: 1)
Ответ на: комментарий от firkax

Насчёт volatile не уверен. Volatile указывает, что компилятор не должен делать предположений о содержимом переменной, но отсюда, вроде, не следует, что нельзя эту переменную записывать в два действия.

JaM
()
Ответ на: комментарий от JaM

Насчёт volatile не уверен. Volatile указывает, что компилятор не должен делать предположений о содержимом переменной

volatile говорит компилятору не кешировать переменную а читать/записывать из/в память сразу. Так как часть памяти может быть отображенно например на PCI карту и тогда запись в эту область это отправка данных на устройство.

V1KT0P ★★
()