Индусские программисты и индусский код

[Интеррапт]

Спокойно усекает до 0

Ну вот еще один аргумент для Аццко, почему для pre-C99 кода - лучше возвращать value != 0, а не просто value

[valchkou]

почитав посты, создается ощущение, что весь этот индусский код написан совсем не индусами

[crypto5]

Ну в джаве и операции не атомарные. Если представить себе сферический одноядерный контупер с переключением контекста промеж потоков, общей памятью и атомарными операциями - то получается разница. каждый дополнительный уровень абстракции будет только добавлять пачку "да, но если ***, то все-таки нет"

С этим не поспоришь

т.е. грубо говоря int на 32 разрядной платформе я могу атомарно записать и прочитать без всяких volatile и interlocked

Что вы вкладываете в слово "могу"? инт на 32 разрядной платформе всегда атомарно читается? Или нужны какие то дополнительные телодвижения?

скажем так: всегда атомарно, если выравнен на границе слова. По умолчанию - это всегда так: что в C++ (до C++11 вообще понятия memory consistency model не существовало), что в C#, что в Java
но можно руками добиться того, чтобы оно не было выравнено правильно (один кусок будет на одной строке кеша, другой на другой), тогда для чтения или записи нужно выполнить 2 чтения (сейчас процессоры сами работают с невыравненными данными, скорее всего операция все равно не атомарна, так как пока читает сам процессор с одной строки, вторая может быть в кеше другого процессора и туда что-то пишут)

Мне кажется в данном случае(в контексте заданной задачки) основной фактор это не выравнивание и количество чтений, а когда программа решит засинхронизировать изменения из кеша/регистров в общую память. Как то неочевидно как без volatile и Atomic* можно такое гарантировать.

[АццкоМото]

Спокойно усекает до 0

Ну вот еще один аргумент для Аццко, почему для pre-C99 кода - лучше возвращать value != 0, а не просто value

Да какой же это аргумент? Возвращать нужно то, что декларируешь, а не абы что - хоть в pre-C99, хоть в С99, иначе ногу так и сяк отстрелишь, не с булами, так в другом месте

[Alexandr]

поспоришь, в Java, как и в C#, как и в C++, всегда можно атомарно прочитать или записать, если размер типа меньше либо равен разрядности шины (проще говоря, размеру регистра), если правильно выравнено, что для простых типов всегда так и для C++ и для C# и для Java. (правда в отличии от C++ на C# и Java long не гарантирован atomic, чтобы не было разницы между 32 разрядной JVM и 64 разрядной)
т.е. грубо говоря int на 32 разрядной платформе я могу атомарно записать и прочитать без всяких volatile и interlocked

конечно операции: чтение + последующая запись, чтение + изменение + запись не атомарны

Смотреть на выделенное и фтыкать тут: http://lurkmore.to/%D0%92%D0%B7%D0%B0%D ... 1%84%D1%8B

Вы ж мой хороший, в Java (как и в C#) примитивные данные изначально всегда (аллокатор любит это делать) выравнены как надо,
а вот если руками лезть (типа Layout.Explicit и Offset в структурах на C# ставить), то можно и кое-что сломать

[Интеррапт]

почитав посты, создается ощущение, что весь этот индусский код написан совсем не индусами

Ну вы как-то предметней что-ли расскажите, кем же этот код написан.

[Alexandr]

С этим не поспоришь

т.е. грубо говоря int на 32 разрядной платформе я могу атомарно записать и прочитать без всяких volatile и interlocked

Что вы вкладываете в слово "могу"? инт на 32 разрядной платформе всегда атомарно читается? Или нужны какие то дополнительные телодвижения?

скажем так: всегда атомарно, если выравнен на границе слова. По умолчанию - это всегда так: что в C++ (до C++11 вообще понятия memory consistency model не существовало), что в C#, что в Java
но можно руками добиться того, чтобы оно не было выравнено правильно (один кусок будет на одной строке кеша, другой на другой), тогда для чтения или записи нужно выполнить 2 чтения (сейчас процессоры сами работают с невыравненными данными, скорее всего операция все равно не атомарна, так как пока читает сам процессор с одной строки, вторая может быть в кеше другого процессора и туда что-то пишут)

Мне кажется в данном случае(в контексте заданной задачки) основной фактор это не выравнивание и количество чтений, а когда программа решит засинхронизировать изменения из кеша/регистров в общую память. Как то неочевидно как без volatile и Atomic* можно такое гарантировать.

для процессора вообще пофигу, когда это произойдет. Есть Cache Coherency Protocol (MESI), есть Processor Consistency Memory Model и этого достаточно (точнее второго достаточно, первое вообще подразумевается by default).
Пофигу абсолютно, хотя когда, впринципе можно и на этот вопрос ответить (Intel x86/x64):
из регистра в кеш - когда инструкция записи в регистр пройдет retirement block и либо попадет в Store Buffer + Read (прочитать строку в кеш), после того как строка придет, оно из Store Buffer сразу попадет в L1, либо сразу в кеш, если данная кеш линия загружена (т.е. Invalid bit сброшен)
из кеша в память - например, на Nehalem архитектере, когда последнему L3 кешу (он inclusive, т.е. включает данные предыдущих кешей) придет сообщение либо Invalidate, либо Read Invalidate

но опять же, это процессору полностью пофигу

[valchkou]

почитав посты, создается ощущение, что весь этот индусский код написан совсем не индусами

Ну вы как-то предметней что-ли расскажите, кем же этот код написан.

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

[Alexandr]

Спокойно усекает до 0

Ну вот еще один аргумент для Аццко, почему для pre-C99 кода - лучше возвращать value != 0, а не просто value

очень часто видел

Code: Select all

return !!value;

[Интеррапт]

очень часто видел

Code: Select all

return !!value;

Да, про это я на прошлой странице уже написал ))

[crypto5]

т.е. грубо говоря int на 32 разрядной платформе я могу атомарно записать и прочитать без всяких volatile и interlocked

Что вы вкладываете в слово "могу"? инт на 32 разрядной платформе всегда атомарно читается? Или нужны какие то дополнительные телодвижения?

скажем так: всегда атомарно, если выравнен на границе слова. По умолчанию - это всегда так: что в C++ (до C++11 вообще понятия memory consistency model не существовало), что в C#, что в Java
но можно руками добиться того, чтобы оно не было выравнено правильно (один кусок будет на одной строке кеша, другой на другой), тогда для чтения или записи нужно выполнить 2 чтения (сейчас процессоры сами работают с невыравненными данными, скорее всего операция все равно не атомарна, так как пока читает сам процессор с одной строки, вторая может быть в кеше другого процессора и туда что-то пишут)

Мне кажется в данном случае(в контексте заданной задачки) основной фактор это не выравнивание и количество чтений, а когда программа решит засинхронизировать изменения из кеша/регистров в общую память. Как то неочевидно как без volatile и Atomic* можно такое гарантировать.

для процессора вообще пофигу, когда это произойдет.

Для процессора может и пофиг, а на возможные результаты выполнения программы это сильно влияет.

[Alexandr]

очень часто видел

Code: Select all

return !!value;

Да, про это я на прошлой странице уже написал ))

прошу прощения, не видел

[Сабина]

А мне очень понравилось код оптимизировать на предмет memory efficiency.
WeakReference SoftReference, ThreadLocal ...
ах

[Alexandr]

Для процессора может и пофиг, а на возможные результаты выполнения программы это сильно влияет.

как? кеш именно и проектировался таким образом, чтобы быть "невидимым" программисту.
Когда попадет из регистра в кеш и в основную память никак не влияет на результаты выполнения программы, ну т.е. совсем
(естественно, я не говорю о производительности и так далее)

[АццкоМото]

поспоришь, в Java, как и в C#, как и в C++, всегда можно атомарно прочитать или записать, если размер типа меньше либо равен разрядности шины (проще говоря, размеру регистра), если правильно выравнено, что для простых типов всегда так и для C++ и для C# и для Java. (правда в отличии от C++ на C# и Java long не гарантирован atomic, чтобы не было разницы между 32 разрядной JVM и 64 разрядной)
т.е. грубо говоря int на 32 разрядной платформе я могу атомарно записать и прочитать без всяких volatile и interlocked

конечно операции: чтение + последующая запись, чтение + изменение + запись не атомарны

Смотреть на выделенное и фтыкать тут: http://lurkmore.to/%D0%92%D0%B7%D0%B0%D ... 1%84%D1%8B

Вы ж мой хороший, в Java (как и в C#) примитивные данные изначально всегда (аллокатор любит это делать) выравнены как надо,
а вот если руками лезть (типа Layout.Explicit и Offset в структурах на C# ставить), то можно и кое-что сломать

Вы ж мой хороший! Вы видели абсолютно все джавы, правда? Даже те, которые еще не выпущены?
Нет никакого секретного свойства в джаве, которое бы гарантировало атомарность даже самого банальнейшего присваивания. Я даже не буду пытаться аргументировать, это просто факт.

[crypto5]

Для процессора может и пофиг, а на возможные результаты выполнения программы это сильно влияет.

как? кеш именно и проектировался таким образом, чтобы быть "невидимым" программисту.
Когда попадет из регистра в кеш и в основную память никак не влияет на результаты выполнения программы
(естественно, я не говорю о производительности и так далее)

Ну вот в примере выше один поток может не увидеть изменения сделанные в другом потоке, потому что они происходят в кеше проца, регистре и т.д. А если поставить volatile и все изменения сразу записываются в основную память, то второй поток все увидит.

[Alexandr]

поспоришь, в Java, как и в C#, как и в C++, всегда можно атомарно прочитать или записать, если размер типа меньше либо равен разрядности шины (проще говоря, размеру регистра), если правильно выравнено, что для простых типов всегда так и для C++ и для C# и для Java. (правда в отличии от C++ на C# и Java long не гарантирован atomic, чтобы не было разницы между 32 разрядной JVM и 64 разрядной)
т.е. грубо говоря int на 32 разрядной платформе я могу атомарно записать и прочитать без всяких volatile и interlocked

конечно операции: чтение + последующая запись, чтение + изменение + запись не атомарны

Смотреть на выделенное и фтыкать тут: http://lurkmore.to/%D0%92%D0%B7%D0%B0%D ... 1%84%D1%8B

Вы ж мой хороший, в Java (как и в C#) примитивные данные изначально всегда (аллокатор любит это делать) выравнены как надо,
а вот если руками лезть (типа Layout.Explicit и Offset в структурах на C# ставить), то можно и кое-что сломать

Вы ж мой хороший! Вы видели абсолютно все джавы, правда? Даже те, которые еще не выпущены?
Нет никакого секретного свойства в джаве, которое бы гарантировало атомарность даже самого банальнейшего присваивания. Я даже не буду пытаться аргументировать, это просто факт.

ути-ути

Variables shared between multiple threads (e.g., instance variables of objects) have atomic assignment guaranteed by the Java language specification for all data types except longs and doubles.

[fruit6]

почитав посты, создается ощущение, что весь этот индусский код написан совсем не индусами

Ну вы как-то предметней что-ли расскажите, кем же этот код написан.

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

точно! в жизни гораздо больше помогает попытка понять мотивацию автора. укрепляет потенц.карму, улучшает отношения с людьми. и как следствие AGI в налоговой декларации.
в догонку: может не работать для фуллтаймеров в краткосрочной перспективе.

[Alexandr]

Для процессора может и пофиг, а на возможные результаты выполнения программы это сильно влияет.

как? кеш именно и проектировался таким образом, чтобы быть "невидимым" программисту.
Когда попадет из регистра в кеш и в основную память никак не влияет на результаты выполнения программы
(естественно, я не говорю о производительности и так далее)

Ну вот в примере выше один поток может не увидеть изменения сделанные в другом потоке, потому что они происходят в кеше проца, регистре и т.д. А если поставить volatile и все изменения сразу записываются в основную память, то второй поток все увидит.

это регулируется спецификацией модели памяти процессора и могут быть связаны далеко не только очередностью помещения в кеш, загрузку в регистр; это также может быть связано с pipeline процессора, может быть еще с чем-то

я и говорил, что нужно смотреть только на спецификацию модели памяти, остальное пофигу

[АццкоМото]

потому что они происходят в кеше проца, регистре и т.д. А если поставить volatile и все изменения сразу записываются в основную память, то второй поток все увидит.

volatile никак не поможет скинуть процессорный кэш в основную память или там записать туда минуя процессорный кэш

[Интеррапт]

Нет никакого секретного свойства в джаве, которое бы гарантировало атомарность даже самого банальнейшего присваивания. Я даже не буду пытаться аргументировать, это просто факт.

Это не совсем так.
Java spec (JLS) гарантирует, что

- Присваивание ссылок - атомарное.
- Присваивание типов int, char, byte, short, boolean, float - атомарное.
- Присваивание double и long с volatile модификатором - атомарное.

[crypto5]

потому что они происходят в кеше проца, регистре и т.д. А если поставить volatile и все изменения сразу записываются в основную память, то второй поток все увидит.

volatile никак не поможет скинуть процессорный кэш в основную память или там записать туда минуя процессорный кэш

Не может, но в джаве оно определяет happens before relation, т.е. гарантируется что присвоение X = 1 увидит второй поток прежде чем первый начнет выполнять if(Y == 1), и тогда два нолика никогда не случатся.
Как это делается на разном железе я ХЗ, я не железячник.

[Dweller]

найти пример мульти-процессора с sequential consistency я не смог хотя в теории они должны существовать, но по поводу джавы вот тут хорошо излагают
http://bartoszmilewski.com/2008/11/11/w ... nsistency/

[crypto5]

найти пример мульти-процессора с sequential consistency я не смог хотя в теории они должны существовать, но по поводу джавы вот тут хорошо излагают
http://bartoszmilewski.com/2008/11/11/w ... nsistency/

Да, это то о чем я тут толкую..

[Albert_al]

Там три раза было на самом деле

Сабине , сеичас разрыдаюсь от нахлынувших воспоминаний(или от смеха)