программистское

[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 и вопреки спекам процессора). Меж тем, никакого абсолютного "раньше и позже" тут нет, поскольку речь идет о чтении данных, записанных двумя разными процессорами. И в этом всё дело.

Comments

[yigal_s]

Собственно, наличие когерентного кэша и делает разговоры о несовпадении данных в кеше вполне неактуальными для программирования. Я правильно понимаю?

Но тогда как раз наличие кэша никакой интересности ситуации не добавляет. (?)

Вот если б заставить программистов жить при некогрентном кеше - вот это было б весело. Правда, я затрудняюсь предположить, повысит ли это общую производительность системы...

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

[panchul.livejournal.com]

Фишка заключается в том, что при дизайне систем дизайнер может _в_принципе_ сделать интерфейс к памяти со всякими глюкавыми эффектами - если дизайнеру есть от этого очень сильная выгода в увеличении производительности. Например в процессорах MIPS (я в MIPS работаю, поэтому приведу в качестве примера) помимо общего интерфейса к памяти и memory-mapped io через кэш и шину OCP - имеется несколько вспомогательных интерфейсов (DSPRAM, ITC), на которые можно навешать custom логику, в которой правила могут не соблюдаться. Обычно DSPRAM ставится как очень быстрая память вместо одного из ways кэша, а ITC - это адреса, обращение к которым позволяет реализовать mailboxes/fifos и семафоры при коммуникации между хардверно-поддерживаемыми тредами. Но на самом деле в принципе дизайнер может сделать custom версию процессора, в котором эти интерфейсы будут использоваться для чего-нибудь другого - например для коммуникации между ядрами некогерентным образом.