программистское
Sep. 19th, 2010 12:32 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
yigal_sдо сих пор не осознавал четко, что время в каждом процессоре бежит по-своему и что никакого опреденного порядка доступа к памяти нет, а есть только видимость с точки зрения каждого процессора.
Ну, скажем, в Intel x86 можно считать, что на каждой команде записи в память стоит release-барьер, а на каждой команде чтения из памяти стоит acquire-барьер, а на каждой lock-инструкции стоит двусторонний барьер, но вот что означает слово "total" в предложении "locked instructions have a total order", и почему об этом вообще надо отдельно говорить, до меня как-то не доходило.
Вот, скажем, и по этой ссылке http://www.bluebytesoftware.com/blog/2008/07/17/LoadsCannotPassOtherLoadsIsAMyth.aspx далеко не последний человек в Микрософте и автор толстенной книжки по мультитреду выглядит смущенным фактом того, что не существует самого по себе "общего порядка", "total order" исполнения операций процессорами. Тот факт, что два процессора могут быть несогласны относительно того, кто из них раньше, а кто позже выполнил свою операцию записи в память он трактует как то, что операции чтения из памяти могут переупорядочиваться (мол, вопреки обещаниям компинии Intel и вопреки спекам процессора). Меж тем, никакого абсолютного "раньше и позже" тут нет, поскольку речь идет о чтении данных, записанных двумя разными процессорами. И в этом всё дело.
Ну, скажем, в Intel x86 можно считать, что на каждой команде записи в память стоит release-барьер, а на каждой команде чтения из памяти стоит acquire-барьер, а на каждой lock-инструкции стоит двусторонний барьер, но вот что означает слово "total" в предложении "locked instructions have a total order", и почему об этом вообще надо отдельно говорить, до меня как-то не доходило.
Вот, скажем, и по этой ссылке http://www.bluebytesoftware.com/blog/2008/07/17/LoadsCannotPassOtherLoadsIsAMyth.aspx далеко не последний человек в Микрософте и автор толстенной книжки по мультитреду выглядит смущенным фактом того, что не существует самого по себе "общего порядка", "total order" исполнения операций процессорами. Тот факт, что два процессора могут быть несогласны относительно того, кто из них раньше, а кто позже выполнил свою операцию записи в память он трактует как то, что операции чтения из памяти могут переупорядочиваться (мол, вопреки обещаниям компинии Intel и вопреки спекам процессора). Меж тем, никакого абсолютного "раньше и позже" тут нет, поскольку речь идет о чтении данных, записанных двумя разными процессорами. И в этом всё дело.
no subject
Date: 2010-09-19 05:45 am (UTC)no subject
Date: 2010-09-19 05:51 am (UTC)В отличие от...?
no subject
Date: 2010-09-19 06:09 am (UTC)no subject
Date: 2010-09-19 05:54 am (UTC)Но тогда как раз наличие кэша никакой интересности ситуации не добавляет. (?)
Вот если б заставить программистов жить при некогрентном кеше - вот это было б весело. Правда, я затрудняюсь предположить, повысит ли это общую производительность системы...
А так, ну и при неупорядоченности доступа к памяти можно вполне с ума сойти, опять же непонятно, чем некогерентный кеш мог бы принципиально усложнить ситуацию по сравнению с тем, что есть уже сейчас на некоторых процессорах.
no subject
Date: 2010-09-19 06:26 am (UTC)no subject
Date: 2010-09-19 06:04 am (UTC)no subject
Date: 2010-09-19 06:09 am (UTC)С другой стороны, общий порядок для некоторых операций вполне определен - вот тот самый "total order". Так что, не все так просто. Два события можно вполне завязать каузальностью. А можно и не завязывать.
Что есть небулевость мира и при чем тут Аксиома Выбора - я не понял, впрочем я в этой области АВ ничего не слышал, кроме слухов.
no subject
Date: 2010-09-19 07:24 am (UTC)no subject
Date: 2010-09-19 08:06 am (UTC)no subject
вопрос о возможности вполне упорядочить множество действительных чисел (мама родная, что ж это будет такое) и вопрос, скажем, наличия времени согласно Ньютоновой механики - это две разные совершено вещи.
no subject
Date: 2010-09-19 05:06 pm (UTC)no subject
Date: 2010-09-19 05:39 pm (UTC)no subject
Date: 2010-09-20 05:36 am (UTC)no subject
Date: 2010-09-21 01:52 am (UTC)Может ли физическая реальность допускать альтернативные аксиоматики - увы, не знаю. Не силен я в этих вопросах.
no subject
Date: 2010-09-21 04:50 am (UTC)no subject
Date: 2010-09-19 05:40 pm (UTC)как связана возможность вполне упорядочить множество действительных чисел и математические модели физических явлений?
no subject
Date: 2010-09-19 06:47 am (UTC)Если бы процессоры работали с памятью напрямую без кеширования и перестановок инструкций, общий порядок достигался бы автоматически.
Но говорить о "total order" нужно потому что хотя load/stores одного потока не переупорядочиваются, переупорядочивание может возникнуть между потоками, (обычно это демонстрируют парами инструкций в 2х разных потоках).
Т.е. store/load имеют total order внутри 1 потока(процессора), а locked инструкции - между всеми.
no subject
Date: 2010-09-19 08:16 am (UTC)А далее, фишка в том, что даже если бы все операции выполнялись бы без перестановок, это по прежднему не гарантировало бы total order.
Например, при наличии той же буферизации записи, каждый процессор видел бы модификации памяти, сделанные другим процессором, с запозданием.
no subject
Date: 2010-09-19 09:01 am (UTC)no subject
Date: 2010-09-19 07:21 am (UTC)no subject
Date: 2010-09-19 07:59 am (UTC)С другой стороны, а вот где в этой самой документации написано, что операция записи, которую делат один процессор, будет вообще хоть когда-то видна другому процессору? :-)
Типа, почему должен выйти следующий цикл?
thread A:
for(;;)
if(flag==1)
break;
thread B:
flag=1;
Он, кстати, может и не выйти, если не объявить flag как volatile - оптимизатор этот самый цикл может переделать так, что flag будет читаться один раз.
Спрашивается - а почему подобная оптимизация не произойдет на уровне железа процессора? Где об этом сказано в документации?
no subject
Date: 2010-09-19 08:15 am (UTC)Написано это например в описании команды move: "the destination operand can be a general-purpose register, segment register or memory location". Никаких кэшей как видишь, запись именно в память. ;)
no subject
Date: 2010-09-19 08:23 am (UTC)и я имел в виду скорее, что процессор не будет читать одну и ту же переменную десять раз подряд в треде А, если он сам ее не менял. Впрочем, если меня - тоже не будет - он же ее и так знает. :-))))
no subject
Date: 2010-09-19 09:00 am (UTC)Но дальше кэша не уйдёт. Кэш и есть его хранилище для часто используемых переменных. А вот чтобы в кэше значение когда надо менялось, за этим механизм синхронизации кэшей следит.
Мне помнится где-то в Intel`овских доках на глаза попадалась фраза, что дескать мы стараемся по мере возможности поддерживать для софта иллюзию того, что он выполняется на тупом CPU без всяких кэшей и прочих наворотов. Но навскидку сейчас не помню где.
no subject
Date: 2010-09-19 03:26 pm (UTC)вопрос лишь в том, в каком пункте спека это отражено.
кэш пофиг. с точки зрения упорядоченности доступа к памяти когерентный кеш неотличи от самой памяти, про него можно забыть.
> что он выполняется на тупом CPU без всяких кэшей и прочих наворотов
угу. тупой ЦПУ для тупого программиста.
no subject
Date: 2010-09-19 05:40 pm (UTC)Пока не специально не оговорено, наличие в описании команды фразы "the destination operand can be a ... memory location", означает, что в результате её выполнения данные доходят до оперативки.
Аналогично с чтением.
Т.е. суть в том, что логика команд соответствует описанию. И процессор не будет пытаться её изменить, а только лишь слегка хитрит. Поэтому пока явно не написано: "CPU будет забивать на чтение данных из переменной, если он туда не пишет", то следует считать, что команда будет выполнять чтение каждый раз.
Короче, это написано в Instruction Set Reference. ;)