год, до тебя самого туго доходит, походу

ты изначально написал, что сплиттится только в 64-битных системах

Ты по ходу мало того что английский не знаешь, так еще и русским не владеешь

Давай так, ты можешь сообразить, по какой причине на архитектуре, где запись 8-байтных значений атомарна, делать такие небезопасные деоптимизации как запись в два этапа?

на что тебя Тимур поправил, что в 32-битных

а по факту, и там, и там

хуевая поправка

причем тут 32 битные

а причем тут 64?

притом что в 32 битной системе не существует 64битных регистров

For references, reads/writes are ALWAYS atomic (even in 64 bit implementations!) For int, char, byte, short, boolean, float, reads/writes are ALWAYS atomic For double and long, if they're volatile, reads/writes are ALWAYS atomic

а по факту, и там, и там

по факту в 32-битных

по факту: мы вам перезвоним

@dmsol прийде, порядок наведе

по факту в 32-битных

где вы в спеках нашли разделение?

Writes to and reads of references are always atomic, regardless of whether they are implemented as 32-bit or 64-bit values.

тут нужен @larev, поллитра и @dmsol)

нет разделения, есть не волатильные long и double которые пишутся в два прохода

не, разговор-то шёл про то, где они НЕ атомарны.

все остальные типы атомарные

если кто-то считает до сих иначе:

Мы вам перезвоним.

Some implementations may find it convenient to divide a single write action on a 64-bit longor double value into two write actions on adjacent 32-bit values. For efficiency's sake, this behavior is implementation-specific; an implementation of the Java Virtual Machine is free to perform writes to long and doublevalues atomically or in two parts. Implementations of the Java Virtual Machine are encouraged to avoid splitting 64-bit values where possible. Programmers are encouraged to declare shared 64-bit values as volatileor synchronize their programs correctly to avoid possible complications.

Я всё сказал.

а причем тут 64?

притом, что надо знать английский, а не тыкать пальцем в небо

Паша

поясни этим $#@@#$@$

@larev

притом, что надо знать английский, а не тыкать пальцем в небо

т.е. ты не согласен, что в 32-битных то же, что и в 64?

т.е. ты не согласен, что в 32-битных то же, что и в 64?

А я где-то это писал?

ну я тебе написал, что по факту и там, и там одинаково, на что мне пишешь, что надо учить английский и вообще все $#@@#$@$

а причем тут 64?

тогда к чему это сообщение?

Получается, что до этого ты не брал во внимание 64битную архитектуру

А теперь выкручиваешься, ай яй яй

к тому, что ты сам изначально написал, будто только в 64

>будто это уже додумывание

Some implementations may find it convenient to divide a single write action on a 64-bit longor double value into two write actions on adjacent 32-bit values. For efficiency's sake, this behavior is implementation-specific; an implementation of the Java Virtual Machine is free to perform writes to long and doublevalues atomically or in two parts. Implementations of the Java Virtual Machine are encouraged to avoid splitting 64-bit values where possible. Programmers are encouraged to declare shared 64-bit values as volatileor synchronize their programs correctly to avoid possible complications.

Пока мистер год ждёт пожарников, ответь, пожалуйста, на такой вопрос. Есть ли на твой взгляд смысл, в том, чтобы делать такую деоптимизацию, чтобы на системе с 64-битной адресацией записывать 8-байтные значения НЕ атомарно? С тем, что имплементация может быть любой, никто не спорит. Вопрос обоснованности.

ты изначально написал, что сплиттится только в 64-битных системах

на что тебя Тимур поправил, что в 32-битных

а по факту, и там, и там

ну давай, покажи мне, где я выкручиваюсь

я скинул сообщение где четко и ясно написано: EVEN IN 64 BIT IMPLEMENTATIONS

Пока мистер год ждёт пожарников, ответь, пожалуйста, на такой вопрос. Есть ли на твой взгляд смысл, в том, чтобы делать такую деоптимизацию, чтобы на системе с 64-битной адресацией записывать 8-байтные значения НЕ атомарно? С тем, что имплементация может быть любой, никто не спорит. Вопрос обоснованности.

Спрашивай лучше @larev, @dmsol, @igorz, я тут просто бот чтобы документацию кидать

мне важно и твоё мнение тоже

Пока мистер год ждёт пожарников, ответь, пожалуйста, на такой вопрос. Есть ли на твой взгляд смысл, в том, чтобы делать такую деоптимизацию, чтобы на системе с 64-битной адресацией записывать 8-байтные значения НЕ атомарно? С тем, что имплементация может быть любой, никто не спорит. Вопрос обоснованности.

А кто её делает?

For references, reads/writes are ALWAYS atomic (even in 64 bit implementations!) For int, char, byte, short, boolean, float, reads/writes are ALWAYS atomic For double and long, if they're volatile, reads/writes are ALWAYS atomic

всё пишется везде атомарно кроме лонга и дабла

Бля всё, ты рили читать не умеешь

For int, char, byte, short, boolean, float, reads/writes are ALWAYS atomic For int, char, byte, short, boolean, float, reads/writes are ALWAYS atomic For int, char, byte, short, boolean, float, reads/writes are ALWAYS atomic

выходит лонг и дабл тоже атомарно пишутся, если волатайл?

да

мне важно и твоё мнение тоже

Я не скилловой, извиняюсь , просто тоже хочу разобраться Это ж знания будут

потому что для волатайл переменных действует отношение хеппенс бефо

Я рулю машину, попозже)

выходит лонг и дабл тоже атомарно пишутся, если волатайл?

да

потому что для волатайл переменных действует отношение хеппенс бефо

Никто, надеюсь, не делает. В параграфе 17.1, который ты так любишь цитировать написано, что есть свобода выбора, и допускается, что некоторые реализации будут записывать НЕ атомарно (например, потому что не все вообще могут). Вот отсюда вопрос, есть смысл записывать НЕ атомарно, там где есть возможность записать сразу?

очевидно, что нет смысла, это как спрашивать: есть ли смысл идти, прыгая на одной ноге по ровной дороге, если можно просто идти на двух ногах?

Год удален из группы за нарушение правил: переход на личности, национализм, расовая неприязнь

говоря неофициальным языком простого народа этой божественной конфы: mr god - pidor

спасибо за внимание, можно работать дальше

?

Дима у нас пожарник, быстро и недорого подгоняет огнетушитель)

Потому что он начал писать с претензией, что официальный документ врёт, а он прав

если бы он задал нормально вопрос, я бы нормально ответил

ERROR: S client not available

ну да, не на дваче, но двач всегда со мной

накатайте ему достойный ответ сюда, а то у меня от него уже личка разогрета

в чем он не прав

конкретно по вашему тех.вопросу

Ну в целом он не прав только в своей высокомерности

нихрена себе))

ну вообще-то мистер год прав)))

на некоторых архитектурах запись лонгов и даблов не атомарна без violatile ))

он нарушил правила

в этом цимес

но 64бит системы и имплементации вм нормально в память пишеь лонги без violatile атомарно) просто спека vm пытается работать на всех архитектурах, появляются костыли))

так что как- бы похуй)

Помянем

Но, посоны, в каком же месте он прав, если он написал, что Лонги и даблы в "два прохода" записываются на 64-битных системах. Я догадывался о том, что у него полыхнёт, но всё равно рискнул его поправить. И тут началось...

Но, посоны, в каком же месте он прав, если он написал, что Лонги и даблы в "два прохода" записываются на 64-битных системах. Я догадывался о том, что у него полыхнёт, но всё равно рискнул его поправить. И тут началось...

он тупа спеку процетировал)) вопрос то не к нему) а к тому какого хуя вообще оно так работает?)

в jvmе вообще много непонятного)

Ща скину его цитатку

непонятно например почему инструкции байткода не полиморфные) почему инстукции есть только для 4х типов)

а их нихрена не 4ре))

Вот жеж она.

ну если только знание о том, что лонг и дабл в 64битных системах записывается в память не атомарно, а в два прохода

шел 2096 год. люди пиздятся из-за типов в жабке

ну если только знание о том, что лонг и дабл в 64битных системах записывается в память не атомарно, а в два прохода

ну так да) и что смущает то?)

в спеке написано что некоторые имплементации дробят записть лонга в пару интов) что явл по умолчанию не атомарной функцие)

можно капнуть как это делает hotspot) я не копал) но сдается мне пишет она не дробя и атомарно)) иначе парней закидают гнилыми помидорами)))

смущает то, что это не правда. Я поправил его оговорку. 1) 32-битная жава не может записывать лонги и даблы атомарно, поэтому она делает так, как в спеке написано. 2) 64-битная жава может записывать, и таки записывает атомарно, посколько нет причин делать иначе, хотя спека это и позволяет.

смущает то, что это не правда. Я поправил его оговорку. 1) 32-битная жава не может записывать лонги и даблы атомарно, поэтому она делает так, как в спеке написано. 2) 64-битная жава может записывать, и таки записывает атомарно, посколько нет причин делать иначе, хотя спека это и позволяет.

верно)

смущает то, что это не правда. Я поправил его оговорку. 1) 32-битная жава не может записывать лонги и даблы атомарно, поэтому она делает так, как в спеке написано. 2) 64-битная жава может записывать, и таки записывает атомарно, посколько нет причин делать иначе, хотя спека это и позволяет.

тебя должно смущать то что надо фигачить violatile даже там где он как бы и не нужен или не надо))))

Могу ли я выступить в защиту God'a?

Он то по делу все говорил, только высокомерно