[c] volatile objects accessing
1) нет
2) да
2) да
2) дадаже если он не уверен что они не алиасятся? как же тогда барьеры работают?
#define mb asm volatile ("": : :"memory")
Для "обычных переменных", а не объектов, доступных через указатель, проблема алиасинга не стоит. Хотя, конечно, мне стоило сразу об этом написать. И, кстати, не факт, что разыменование volatile int* в C является барьером — из-за type-based pointer disambiguation.
По стандартуинтуитивный ответ
1) компилятор имеет право переставлять обращения к разным volatile переменным?
2) компилятор имеет право переставлять обращение volatile переменной и запись в "обычную" переменную?
1) да
2) да
не вижу препон, буду рад услышать обоснованные опровержения моего необоснованного мнения
1) данеопределённость в порядке доступа к volatile объектам есть только между sequence points
спс, а вот насчет второго вопроса это в стандарте явно где-то написано?
потому что я пока не понял, если опираться только на стандарт, то ли он это явно разрешает , то ли об этом умалчивает (типа implementation defined) и де-факто некоторые компиляторы переставляют (кстати, такие компиляторы есть? т.е. пример иходника, компилятора и чтобы в ассемблере было видно что обращения переставились)
Самое, как мне кажется, близкое из стандарта, что я нашел:
The least requirements on a conforming implementation are:
— At sequence points, volatile objects are stable in the sense that previous accesses are
complete and subsequent accesses have not yet occurred.
...
но тут ничего не говорится про не volatile objects...
потому что я пока не понял, если опираться только на стандарт, то ли он это явно разрешает , то ли об этом умалчивает (типа implementation defined) и де-факто некоторые компиляторы переставляют (кстати, такие компиляторы есть? т.е. пример иходника, компилятора и чтобы в ассемблере было видно что обращения переставились)
Самое, как мне кажется, близкое из стандарта, что я нашел:
The least requirements on a conforming implementation are:
— At sequence points, volatile objects are stable in the sense that previous accesses are
complete and subsequent accesses have not yet occurred.
...
но тут ничего не говорится про не volatile objects...
На твои вопросы действительно краткие ответы будут 1) нет 2) да
Категорически рекомендую прочитать статью
C++ and the Perils of Double-Checked Locking
Scott Meyers and Andrei Alexandrescu
September 2004
http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf
Там как раз про гарантии стандарта по поводу порядка доступа и volatile
Категорически рекомендую прочитать статью
C++ and the Perils of Double-Checked Locking
Scott Meyers and Andrei Alexandrescu
September 2004
http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf
Там как раз про гарантии стандарта по поводу порядка доступа и volatile
да , мне судя по всему нужны какие-нибудь "комментарии"
спс за ссылку, ща почитаю...
спс за ссылку, ща почитаю...
C++ and the Perils of Double-Checked LockingСпасибо. Каждый раз читаю что-то подобное и удивляюсь, как программы на C/C++ вообще работают.
Scott Meyers and Andrei Alexandrescu
September 2004
http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf
ты много знаешь программ (особенно на c++) где активно используется самодельная синхронизация?
В смысле, межпотоковая, не используя библиотеки типа pthreads? Не знаю ни одной. А это меняет суть дела?
такие библиотеки пишут и тестируют умные люди
Ты, ээ, читал указанный документ? Я не понимаю, чего ты привязался к этим библиотекам. Использовать "крутую" библиотеку не значит написать работающей программы.
конечно нет
правильно использовать правильную библиотеку значительно проще
правильно использовать правильную библиотеку значительно проще
"конечно нет" видимо относится к вопросу "Ты, ээ, читал указанный документ?"
Ты знаешь какую-нибудь библиотеку для плюсов, предоставляющую lightweight инициализацию синглтонов?
Ты знаешь какую-нибудь библиотеку для плюсов, предоставляющую lightweight инициализацию синглтонов?
да
не знаю. проблема чтоб сделать это без лока когда его создавать ломится куча трэдов?
не знаю. проблема чтоб сделать это без лока когда его создавать ломится куча трэдов?
Оставить комментарий
evolet
Вопросы по обращениям к volatile - переменнымПо стандарту
1) компилятор имеет право переставлять обращения к разным volatile переменным?
2) компилятор имеет право переставлять обращение volatile переменной и запись в "обычную" переменную?
курил стандарт, но не могу докурить...( (возможно, отчасти из-за недостаточного знания английского)
там написано, что expression reffering to such an object (volatile то бишь) должны вычисляться строго в сответсвии с abstract semantic, а по abstract semantic все обращения к volatile-переменным, записи во все переменные oбъявляются как имеющие side effect (и =>, как я понимаю, не могут быть переставлены). Но в то же время, сказано, что actual semantic (то бишь, то, что позволено делать копмилятору) может отличаться от abstract (но должна совпадать на вызовах, пересекающих compilation unit boundaries и еще где-то). Ну а если речь просто о последовательном коде внутри одной функции, то какие будут ответы на первые два вопроса?