Здравствуйте, ·, Вы писали:
·>После очередной подмены тезис стал заключаться в том, что atomic<int>+relaxed и volatile sig_atomic_t — оба атомарны с т.з. многопоточности т.к. генерят одинаковый код. Я показал, что иногда генерится разный код. ЧТД.
Не-не-не, Дэвид Блэйн, вы показывали Алексу, что в одном случае атомарность, а в другом нет.
Тем самым ты и Сайберикс показали, что не понимаете, что есть атомарность, путаете её с упорядочиванием/синхронизацией.
А я лишь утверждал о требовании записи значения в память в одну инструкцию из-за работы в условиях прерываний.
Для x86 таких инструкций несколько, кстате.
·>Но ты снова подменяешь тезис какими-то конкретными имплементациями:
Я показал тебе, что не понимаешь ассемблерного кода, который сам же привёл.
V>>У тебя по ссылке swap, но чтение содержимого переменной не требовалось, там безусловная запись, поэтому, скорее всего, будет работать "can optimize away fetching the original value".
·>И что, что скорее всего? А иногда и нет. Типичный UB.
В голос уже ))
1. "Скорее всего" относится не к описанному поведению, а к конкректной реализации проца под этот ассемблер;
2. Даже если в какой-то из реализаци в этой команде будет происходить не store, а swap — во втором случае всё-равно никакого UB.
V>>Итого, когда биты aq=0 и rl=0 у этих операций и чтение значения не требуется (см в твоём примере amoswap.w zero, ...), семантика происходящего не будет отличаться от простого sw.
·>Если implement AMOs at memory controllers. А если нет?
То на уровне проца, вестимо.
А у тебя какие варианты?
V>>If the address is not naturally aligned, a misaligned address exception will be generated.
·>Ты хочешь сказать, что это единственная причина?
Да.
Это слишком веская причина.
Лично я бы предпочел иметь в x86/x86_x64 инструкции, которые генерят аналогичное прерывание в случае нарушения выравнивания.
Что характерно, что в x86/x86_x64 если невыровненное значение попадай на край линейки кеша, то прерыванеи происходит ВСЕГДА, но это прерывание перехвачено операционкой и операционка сама "ручками" разруливает такую ситуацию, копируя это значение побайтно. Т.е. и эффективность падает и атомарности никакой, а программист и не в курсе. Хотелось бы иметь возможность каким-либо образом указывать в некоторых случаях на то, что ничего разруливать не надо, надо явно сигнализировать об ошибке.
·>Почему тогда сгенерился такой код? Ведь компилятор явно знает, что оно aligned.
Ты так говоришь, будто современные компиляторы — верх разума.
Это шаблон генерации, скорее всего, который работает для разных случаев адресации в том числе.
Я дважды находил ошибки в gcc в разное время, а тут и ошибки-то нет, придраться не к чему.
Могу показать выход работы, например, JIT дотнета, где происходят явные глупости, которые хотелось бы исправить.
Т.е. не боги горшки обжигают, а обычные люди, не большей квалификации, чем в среднем участники этого форума.
·>В любом случае, даже если risc и все известные архитектуры будут атомик по самые гланды, это не меняет того факта, что по стандарту _языка_ ни int, ни даже volatile int не являются atomic.
По стандарту sig_atomic_t в любом случае будет atomic.
Помнишь из этой ветки:
http://www.rsdn.org/forum/flame.comp/7460799.1
Мякотка в том, что тебе никто не запрещает вызывать тот хенлдер сигнала ручками из другого потока.
Симметричная мякотка в том, что в многопроцессорной системе обработчик прерывания может быть вызыван из другого потока (из основного), а не из того, в котором ты осуществляешь оперироавние с переменной типа sig_atomic_t.
А будет ли этот typedef на short, int, long — лично мне до фени.
Но если уже спорить ради спора, я бы запросто поставил ящик коньяка на то, что в 99,9% всех реализаций это будет int. ))
