AZ
А почему 4-ый поток не увидит нужных данных, там же чтение тоже идет по acuqire
а это неважно
Size: a a a
2020 January 10
AS
сошлюсь на себя любимого: https://shipilev.net/blog/2016/close-encounters-of-jmm-kind/#myth-reorderings-and-commit
I
Обрабатываю информацию.
AS
или на более авторитетное: https://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test7.pdf (Ctrl-F "IRIW")
AS
Оно не объясняет прямо, почему не хватает rel/acq, а нужно именно seqcst, но с точки зрения языковых гарантий дело именно там. Оно и в Java так, и с C/C++, и где только не.
I
Курю, выглядит нужным и полезным. Если будут вопросы - отпишу.
I
Спасибо товарищам выше!
AS
Мне чтоб потом не возвращаться, сразу вобью гвоздь.
Примеры типа IRIW показывают слабость Acq/Rel относительно SeqCst. То, что какие-то там два проца сделали два rel, а потом какие-то два проца сделали acq, не говорит, что два rel-а "ушли в память" в каком-то одном порядке, а два acq-а "прочитали из памяти" в каком-то одном порядке. Acq/Rel только говорит, что всё зарелиженное "в это место" будет увидено эквайрящими "из этого места" процами, точка. С другими acq/rel эта гарантия связана очень слабо (можно считать, что вообще не). Хотите связывать операции на разных процах глобальным порядком -- это к sequential consistency. Поэтому для IRIW нужен более сильный memorder::seq_cst (или как он там называется в C11).
В этом смысле acq/rel -- это штука, которая хорошо ложится на всякие распределённые системы (одна нода послала конверт, другие ноды его полностью приняли), а вот seqcst требует извращённых протоколов консенсуса (все ноды согласились, что конверт вообще был послан, что его порядок относительно других конвертов именно такой, етц)...
Примеры типа IRIW показывают слабость Acq/Rel относительно SeqCst. То, что какие-то там два проца сделали два rel, а потом какие-то два проца сделали acq, не говорит, что два rel-а "ушли в память" в каком-то одном порядке, а два acq-а "прочитали из памяти" в каком-то одном порядке. Acq/Rel только говорит, что всё зарелиженное "в это место" будет увидено эквайрящими "из этого места" процами, точка. С другими acq/rel эта гарантия связана очень слабо (можно считать, что вообще не). Хотите связывать операции на разных процах глобальным порядком -- это к sequential consistency. Поэтому для IRIW нужен более сильный memorder::seq_cst (или как он там называется в C11).
В этом смысле acq/rel -- это штука, которая хорошо ложится на всякие распределённые системы (одна нода послала конверт, другие ноды его полностью приняли), а вот seqcst требует извращённых протоколов консенсуса (все ноды согласились, что конверт вообще был послан, что его порядок относительно других конвертов именно такой, етц)...
I
Мне чтоб потом не возвращаться, сразу вобью гвоздь.
Примеры типа IRIW показывают слабость Acq/Rel относительно SeqCst. То, что какие-то там два проца сделали два rel, а потом какие-то два проца сделали acq, не говорит, что два rel-а "ушли в память" в каком-то одном порядке, а два acq-а "прочитали из памяти" в каком-то одном порядке. Acq/Rel только говорит, что всё зарелиженное "в это место" будет увидено эквайрящими "из этого места" процами, точка. С другими acq/rel эта гарантия связана очень слабо (можно считать, что вообще не). Хотите связывать операции на разных процах глобальным порядком -- это к sequential consistency. Поэтому для IRIW нужен более сильный memorder::seq_cst (или как он там называется в C11).
В этом смысле acq/rel -- это штука, которая хорошо ложится на всякие распределённые системы (одна нода послала конверт, другие ноды его полностью приняли), а вот seqcst требует извращённых протоколов консенсуса (все ноды согласились, что конверт вообще был послан, что его порядок относительно других конвертов именно такой, етц)...
Примеры типа IRIW показывают слабость Acq/Rel относительно SeqCst. То, что какие-то там два проца сделали два rel, а потом какие-то два проца сделали acq, не говорит, что два rel-а "ушли в память" в каком-то одном порядке, а два acq-а "прочитали из памяти" в каком-то одном порядке. Acq/Rel только говорит, что всё зарелиженное "в это место" будет увидено эквайрящими "из этого места" процами, точка. С другими acq/rel эта гарантия связана очень слабо (можно считать, что вообще не). Хотите связывать операции на разных процах глобальным порядком -- это к sequential consistency. Поэтому для IRIW нужен более сильный memorder::seq_cst (или как он там называется в C11).
В этом смысле acq/rel -- это штука, которая хорошо ложится на всякие распределённые системы (одна нода послала конверт, другие ноды его полностью приняли), а вот seqcst требует извращённых протоколов консенсуса (все ноды согласились, что конверт вообще был послан, что его порядок относительно других конвертов именно такой, етц)...
А то есть если у нас, один поток делает acq переменной a, а два другие ее release - то изменения гарантированно только один из них увидит?
I
Или оба... :?
AS
Ммм? Один поток сделает release, а другие два сделают acquire на той же переменной? Всё зарелиженное увидят "оба два" проца.
I
Последовательность действий такая: первый тред пишет x = true; второй тред пишет y = true; третий тред читает x = true, но не видит y = true, не инкрементит z; четвёртый делает то же самое, но в другую сторону.
Тогда все равно не понимаю, у нас же третий тред делает acq переменной, почему он ее не видит ТТ ?
AS
А почему должен? ;)
I
потому что первый поток делает ее release?
I
Ммм? Один поток сделает release, а другие два сделают acquire на той же переменной? Всё зарелиженное увидят "оба два" проца.
как тут
AS
Так-так, это типичный ментальный импеданс, пристегнитесь.
AS
Проще на примере:
Thread 1:
x = 1;
"release" g = 1;
Thread 2:
r1 = "acquire" g;
r2 = x;
Thread 1:
x = 1;
"release" g = 1;
Thread 2:
r1 = "acquire" g;
r2 = x;
AS
Возможен ли случай (r1, r2) = (0, 0)?
AS
(Это не риторический вопрос, я подожду)
I
Если поток 2 выполнился раньше чем второй, то возможно