Здравствуйте, StanislavK, Вы писали:
SK>не относящийся к теме вопрос. Какое отношение в c/c++ volatile имеет к барьерам? Оно же, вроде как, просто оптимизации на уровне компилятора запрещает? Спрашиваю, потому, что реально не знаю и интересно, что знающие люди скажут.
volatile обычно связывают с видимостью переменной, разделяемой несколькими потоками, но у
нее есть и другое применение. Чтение и запись volatile-переменных неявно ставит барьер памяти.
Причем ввиду известных особенностей hardware reordering на x86 этот барьер неполный (не fence).
А вот с обеспечением атомарности volatile никак не связан, вопреки расхожему мнению.
Ой, тут все в двух словах не описать.
Здравствуйте, enji, Вы писали:
E>Тут как ты понимаешь, все зависит от протокола. Если протокол простой (как тот, что я имел в виду), то там все просто. CRC там обычный xor, обрыв связи устройство не колышит, протокол вида запрос-ответ, накладывается на обычную стейт-машину.
Ну да, естетсвенно, от протокола (и физического транспорта). Плюс обязательная обработка таймаутов. Вы же сами хотели кормить неверный ввод, а ошибки в передаче на устройство более важная проблема.
M>>Выделенное особенно плохо. Откуда вы такое вообще берете? ....
E>Опять таки все зависит от протокола. В данном конкретном достаточно таблицы команда — функция-обработчик E>Если реализовать ее не в виде switch, то можно будет добавлять новые команды динамически — например в зависимости от конфигурации. Или на одном хоботе поддерживать одни команды, а на другом — другие.
А почему в виде таблицы? Почему от конфигурации? Может, их нужно вообще с устройством согласовывать на самом деле? Кстати, а как устройство реагирует на неподдерживаемые (и неполностью полученные) команды? Там дополнительного восстановления не потребуется? Почему вообще обработка различных команд должна производиться на уровне устройства? Может, драйвер должен поддерживать все различные команды, а выбор должен делаться на другом уровне (ввода команд, например). Может, все команды можно описать вообще формально преобразованием из формата команды в пакет и обратно, тогда весь протокол будет задаваться кофнигом. Или будут "модальные" команды. Например, "войти в режим конфигурации", в котором до выхода действует свой набор команд. Этот вариант в вашу табличку хорошо ляжет?
Вот исходя из всех этих вопросов и не понятно, почему кандидат должен прийти к тому решению, которое вы хотите. Для простейшей задачи (даже с добавлением) табличка обработчиков — типичный overengeneering, там для решения if/of или case'ов более чем достаточно (особенно если ввод ручками парсить и на ошибки проверять!). А для корректного выбора более сложной схемы недостаточно данных. С реальном устройстом и приложением чуть попроще, там и круг комад ограничен, и сценарии использования более-менее очевидны.
Здравствуйте, okman, Вы писали:
O>Здравствуйте, StanislavK, Вы писали:
SK>>не относящийся к теме вопрос. Какое отношение в c/c++ volatile имеет к барьерам? Оно же, вроде как, просто оптимизации на уровне компилятора запрещает? Спрашиваю, потому, что реально не знаю и интересно, что знающие люди скажут.
O>volatile обычно связывают с видимостью переменной, разделяемой несколькими потоками, но у O>нее есть и другое применение. Чтение и запись volatile-переменных неявно ставит барьер памяти. O>Причем ввиду известных особенностей hardware reordering на x86 этот барьер неполный (не fence). O>А вот с обеспечением атомарности volatile никак не связан, вопреки расхожему мнению. O>Ой, тут все в двух словах не описать.
volatile запрещает некоторые оптимизации компилятора и все. Область видимости переменной,
разделяемой потоками — одно из применений такого поведения как следствие. Никакие барьеры
памяти при обращении к volatile переменной не ставятся, запрещается лишь reordering с другими
volatile переменными на уровне компилятора (но компилятор может сделать reordering с
другими не-volatile переменными). Барьеры компилятора (для всех видов переменных) можно поставить
явно с помощью специальных конструкций или интринсиков.
Однако, даже если компилятор сгенерировал код в том порядке, что и в исходнике, сам процессор
может сделать reordering; cpu про volatile и барьеры компилятора ничего не знает. Тут нужны
барьеры памяти (mfence и пр.).
Еще один важный момент (не последний). Простое чтение volatile переменной не обязательно даст
последнее, "самее свежее значение", т.к. чтение может произойти из кеша cpu а не из RAM, а
volatile не обеспечивает когерентность кешей процессоров. Тоже решается хардварными барьерами
памяти.
Здравствуйте, vshemm, Вы писали:
V>Никакие барьеры памяти при обращении к volatile переменной не ставятся.
Чтение или запись из volatile-переменной и выступает таким барьером.
На x86 и amd64, за некоторыми исключениями, о которых необходимо знать разве что разработчикам
операционных систем, возможна только одна комбинация инструкций, которая подвержена hardware
reordering — это запись-чтение. Поэтому, когда встречается чтение из volatile, оно может быть
переупорядочено только в одном случае — если предшествующая операция была операцией записи.
Значит, есть гарантия, что чтение из volatile будет гарантированно выполнено до любых следующих за
ним операций (acquire semantics), поскольку ни load-load, ни load-store не переупорядочиваются.
Аналогично, операция записи в volatile может быть переупорядочена только со следующей за ней
операцией чтения, а значит гарантирует, что запись будет выполнена после всех предшествующих ей
операций (release semantics).
V>Однако, даже если компилятор сгенерировал код в том порядке, что и в исходнике, сам процессор V>может сделать reordering; cpu про volatile и барьеры компилятора ничего не знает. Тут нужны V>барьеры памяти (mfence и пр.).
Не может процессор сделать reordering операции store, если до нее была load.
Операция чтения или записи в volatile позволяет контролировать этот аспект (см. выше), поэтому ее
действие логически эквивалентно барьеру, хотя формально она им не является.
Ну я же написал в исходном сообщении: "неявно ставит барьер памяти".
V>Еще один важный момент (не последний). Простое чтение volatile переменной не обязательно даст V>последнее, "самее свежее значение", т.к. чтение может произойти из кеша cpu а не из RAM, а V>volatile не обеспечивает когерентность кешей процессоров. Тоже решается хардварными барьерами V>памяти.
volatile дает гарантию (не по Стандарту, но по факту) что чтение или запись будут осуществляться
через память, а не, скажем, через регистр процессора. На кэш-когерентных архитектурах этого
достаточно, поскольку когерентность обеспечивается аппаратно и один процессор никогда не
получит неверное значение ячейки памяти, если до этого ее обновил другой процессор.
Здравствуйте, okman, Вы писали:
O>Здравствуйте, vshemm, Вы писали:
V>>Никакие барьеры памяти при обращении к volatile переменной не ставятся.
O>Чтение или запись из volatile-переменной и выступает таким барьером. O> ....
Нет. Есть 2 типа барьеров — компилятора и памяти (хардварный). Они независимы, за исключением того,
что оптимизатор может знать про целевую архитектуру. Путать их никак нельзя. Барьеры компилятора
действуют на уровне генерации кода, на уровне выдаваемых асмовских иснструкций, грубо говоря.
Обращение к volatile ставит слабый барьер компилятору — нельзя переупорядочивать эту операцию
с операциями с другими volatile. Сильный барьер запрещает reordering для всех переменных. Все.
V>>Однако, даже если компилятор сгенерировал код в том порядке, что и в исходнике, сам процессор V>>может сделать reordering; cpu про volatile и барьеры компилятора ничего не знает. Тут нужны V>>барьеры памяти (mfence и пр.).
O>Не может процессор сделать reordering операции store, если до нее была load. O>Операция чтения или записи в volatile позволяет контролировать этот аспект (см. выше), поэтому ее O>действие логически эквивалентно барьеру, хотя формально она им не является. O>Ну я же написал в исходном сообщении: "неявно ставит барьер памяти".
Может, даже х86 (сами признали, что некоторые делают reordering и для store; если что, могу привести
пример, когда x86 процессоры в одной линейке имеют разное поведение). volatile этот процесс
никак не контролируют, т.к. на уровне команд процессора обращение что к обычной, что к volatile
переменной выглядит одинаково. У процессора нет информации времени кодогенерации.
Еще раз, интерпретация должна быть такой: "неявно ставит слабый барьер компилятора".
V>>Еще один важный момент (не последний). Простое чтение volatile переменной не обязательно даст V>>последнее, "самее свежее значение", т.к. чтение может произойти из кеша cpu а не из RAM, а V>>volatile не обеспечивает когерентность кешей процессоров. Тоже решается хардварными барьерами V>>памяти.
O>volatile дает гарантию (не по Стандарту, но по факту) что чтение или запись будут осуществляться O>через память, а не, скажем, через регистр процессора. На кэш-когерентных архитектурах этого O>достаточно, поскольку когерентность обеспечивается аппаратно и один процессор никогда не O>получит неверное значение ячейки памяти, если до этого ее обновил другой процессор.
По факту тоже не дает (разве что на genuine intel и некоторых других cpu/архитектурах). Завязываться
на такое поведение — как минимум не кроссплатформенно.
Обращение к памяти идет через кеши процессора, и неизвестно, когда оно достигнет RAM. Когерентность
обеспечивается аппаратно, но не автоматически-"прозрачно", поэтому возможна ситуация, что я описал.
Опять же, volatile тут совсем не в кассу.
Пожалуйста, не смешивайте уровень компилятора (кодогенерации), только на который и влияет volatile,
и уровень аппаратуры. Грабли могут быть эпических масштабов.
Уточнение Говоря про кеши я подразумеваю L1-L2-L3 как одного процессора, так и разных.
Под когерентностью я понимаю когерентность кешей разных процессоров, а не локальных.
Т.е. переменную меняет ДРУГОЙ процессор, а мы на нашем читаем локальную копию. Из разных нитей.
И физически, а не логически одновременно (+- 200ns скажем).
Здравствуйте, vshemm, Вы писали:
O>>Чтение или запись из volatile-переменной и выступает таким барьером.
V>Нет. Есть 2 типа барьеров — компилятора и памяти (хардварный). Они независимы, за исключением того, V>что оптимизатор может знать про целевую архитектуру. Путать их никак нельзя.
Какая еще путаница ? Я ведь конкретно написал. Запись или чтение volatile происходит через память, —
это гарантируется компилятором, — а операции чтения или записи в память влияют на переупорядочивание
самым непосредственным образом. Предположим, вот есть такой код:
int volatile val1;
int volatile val2;
val1 = 100;
val2 = 200;
Здесь гарантируется, что процессор будет выполнять запись в порядке val1-val2, но никогда не наоборот,
причем эта гарантия основывается исключительно на особенностях архитектуры, а не на поведении компилятора,
хотя и оно тоже сказывается, так как он не станет изменять порядок обращения к volatile-данным.
И для данного примера не требуется вставлять никаких дополнительных барьеров — ни компиляторных,
ни особенно хардварных, так как это лишь приведет к дополнительным накладным расходам.
У нас уже есть барьер в виде того, что комбинация запись-запись [просто так] не переупорядочивается.
А вот если написать по-другому:
int volatile val1;
int volatile val2;
val1 = 100;
int a = val2;
то независимо от того, что используется volatile, чтение переменной val2 может случиться до
записи в переменную val1, опять же исключительно ввиду особенностей архитектуры, которая
допускает reordering для данной комбинации. Вот в таких случаях, если порядок выполнения данных
операций важен, и требуется настоящий хардварный барьер — lock, fence и т.д.
V>Барьеры компилятора действуют на уровне генерации кода, на уровне выдаваемых асмовских иснструкций, V>грубо говоря. Обращение к volatile ставит слабый барьер компилятору — нельзя переупорядочивать эту V>операцию с операциями с другими volatile. Сильный барьер запрещает reordering для всех переменных. Все.
Очевидно, не все. См. выше.
V>Еще раз, интерпретация должна быть такой: "неявно ставит слабый барьер компилятора".
Что значит "слабый" ? Неспособный влиять на hardware reordering ?
Ок. Сможете привести пример кода для x86 или amd64 а-ля тест Деккера, который бы доказал,
что запись или чтение volatile-данных не сказывается на hardware reordering ? Уверен, что нет.
V>Может, даже х86 (сами признали, что некоторые делают reordering и для store; если что, могу привести V>пример, когда x86 процессоры в одной линейке имеют разное поведение).
Приведите. Только не надо возвращаться к архаичным 80486.
V>volatile этот процесс никак не контролируют, т.к. на уровне команд процессора обращение что к V>обычной, что к volatile переменной выглядит одинаково. У процессора нет информации времени кодогенерации.
Кто ж спорит.
Вот только чтение или запись в память выполняется процессором, а не компилятором, а операции
доступа к памяти сказываются на переупорядочивании и могут его ограничивать. О чем я тут и талдычу.
V>Обращение к памяти идет через кеши процессора, и неизвестно, когда оно достигнет RAM. Когерентность V>обеспечивается аппаратно, но не автоматически-"прозрачно", поэтому возможна ситуация, что я описал. V>Опять же, volatile тут совсем не в кассу.
Для программы не имеет значения откуда она получила данные — реально из памяти или из кэша.
До тех пор, пока остальные процессоры "видят" то же самое значение через различные механизмы
синхронизации, в том числе через когерентность кэша. С другими архитектурами я не работал,
так что про них сказать не могу.
V>Пожалуйста, не смешивайте уровень компилятора (кодогенерации), только на который и влияет volatile, V>и уровень аппаратуры. Грабли могут быть эпических масштабов.
На что и как влияет volatile я уже написал выше. Никто не говорил о какой-то дополнительной
"волшебной" кодогенерации, сопутствующей volatile, речь о чисто хардварных вещах — чтение и запись в
память, которая неявным образом влияет на hardware reordering. volatile тут, по сути, вообще не
при чем, просто если использовать обычную, не-volatile переменную, нет гарантии, что компилятор не
"закэширует" ее в каком-нибудь регистре, а в случае volatile такая гарантия у нас есть.
E>>Дать "домашнее задание" по теме работы (~2-4 часа). К примеру: "Вот описание протокола управления устройством. Напишите программу, которая принимает стандартный ввод, выделяет из него команды и отвечает на них в стандартный вывод. Пока требуется реализовать поддержку только указанных команд (скажем, 4 или 5). Предусмотрите возможность добавления новых команд."
M>Плохая задача. Она очень муторная в обработке ошибок. Различные обрывы (и восстановления) связи с устройством, расхождения в контрольной сумме и прочие радости. Включая необходимость переотправки в некоторых случаях пакета с хоста (по таймауту).
Ну, просто переотправка — это довольно просто. А так — согласен, обработка ошибок при общении с девайсом — это в реальном мире довольно сложный кейс, если мы говорим о автономной работе комплекса, когда нет возможности сообщить юзеру "произошла фигня, что делать будем?".
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
E>>>А за что тут платить? Т>>За трату времени.
E>Не всякая трата времени оплачивается. E>ты посетил собеседование, потратил время, но тебе за него не заплатили
А ведь это мысль!
Большинство контор в нашей местности платит около 1000$ сотруднику, рекомендовавшему друга, если последний прошел собеседу и устроился на работу. Так почему я, пришедший на работу сам, и рекомендующий сам себя, должен лишаться этой суммы? Заодно хоть отчасти окупит геморрой с собеседованиями. При следующей смене работы обязательно буду HR-ам предъявлять подобные размышления.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, enji, Вы писали:
E__>>А вот дальше я бы, как минимум, разделил примерный ход собеседования на минимум 2 градации: начинающий, но толковый(бестолкового уже можно провожать), или опытный. Потому как вопросы ниже вызовут зевоту у опытного.
E>Согласен, тоже об этом думал. С другой стороны — ну позевает чел 10 минут — какие проблемы
Не забывай: собеседование, оно двухстороннее. Человек компанию и собеседующего оценивеат не менее(а чаще и более), чем компания его. Позевает, и напишет в своем графике собеседований напротив вашей конторы что-то типа "квалификация собеседующего ниже плинтуса, контора — говно, решение — отказ". У меня при последней смене работы подобные записи получили 8 компаний(2 было выделено как особый трэш), хотя они все мне предлагали оффер.
Хотя, может, это специфика большого города, где чаша весов на рынке труда IT сильно перевешена в сторону работника.
E__>>Несмотря на то, что задание вроде бы и несложное(я надеюсь, протокол-то хоть простой? А то бывают и многоуровневые с хитрым шифрованием, проверкой целостности и нетривиальными алгоритмами обработки ошибок для возвращения в рабочее состояние, это уже не лезет ни в какие ворота), я бы отказался писать.
E>Меня тут уже убедили отказаться от тестового задания, если чел может показать свой код на гитхабе скажем. Как тебе такой вариант?
Ну, в си(++?) качество кода может решать больше, чем в более привычных мне языках(слишком много нюансов). На той же жабе, где "как думается, так и пишется", вполне достаточно оценить общий уровень, смотреть на код не особо есть смысл — там трудно написать как-то по-извращенному. Ну а если человек понимает некоторые важные моменты, то врядли у него плохое качество кода.
В случае си, код на гитхабе, и пару вопросов по случайным кускам(чтобы понять, что они не левые) — вполне достаточно, имхо.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Alexéy Sudachén, Вы писали:
E>>Гм. Наверное зависит от задачи. Если состояния 2-3-4-5 то возни с твоим генератором будет на порядки больше.
AS>Команд или состояний? Очевидно что если команд пять, то при сетевом обмене состояний в несколько раз больше. Но однако сие вопрос практики и тех нескольких команд которые надо добавить. О них же как бы заранее не известно. Как бы понятно, что логика состоит из типового применения утильного кода, а вся веселуха заключается в корректном протаскивании и пакетов в нужном порядке и обработки всяких ножидонностей. Мы же типа говорим не про сделать шоб запустилось, а про демонстрацию профессионального подхода и навыков. Не?
Нормальная реализация failover в рамках даже довольно простого протокола уже несколько выходит за пределы "простой задачи на пару часов". В рамках чуть более сложного — это уже реальная задача, решать которую нахаляву — глупость. В немалой степени из-за того, что в доках к девайсам я _никогда_ не видел полного описания всех возможных flow, остальное додумывать и доделывать самому. Может, ТС живет в мире эльфов, и там всегда есть более чем развернутая документация по устройствам. Я живу в реальном мире, где иногда единственное, что есть — это двойной автоперевод китайский-->английский-->русский(без оригиналов, есть в наличии только этот "русский" вариант), и несколько логов с перепиской каких-то индусов с кошмарным английским... Как хорошо, что хотя-бы цифры во всех языках одинаковы.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
SK>>не относящийся к теме вопрос. Какое отношение в c/c++ volatile имеет к барьерам? Оно же, вроде как, просто оптимизации на уровне компилятора запрещает? Спрашиваю, потому, что реально не знаю и интересно, что знающие люди скажут.
O>volatile обычно связывают с видимостью переменной, разделяемой несколькими потоками, но у O>нее есть и другое применение. Чтение и запись volatile-переменных неявно ставит барьер памяти. O>Причем ввиду известных особенностей hardware reordering на x86 этот барьер неполный (не fence). O>А вот с обеспечением атомарности volatile никак не связан, вопреки расхожему мнению. O>Ой, тут все в двух словах не описать.
В том-то и дело, что ТС этот вопрос ставит в один ряд с "переверните строку". А это умения и знания радикально разного уровня. Даже в жабе, где все более причесано, volatile имеет ряд неявных особенностей. В сях, с их низким уровнем, этих особенностей масса(какой компилятор, какая архитектура?).
А теперь вопрос: если человек нормально отвечает и рассказывает все нюансы при использовании volatile, стоит ли его грузить унылыми вопросами про переворот строки и прочим? Может ли человек, понимающий, как работает этот барьер памяти на уровне разных архитектур, не понимать указателей? Или чего-то еще?
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Eugeny__, Вы писали:
E__>В том-то и дело, что ТС этот вопрос ставит в один ряд с "переверните строку". А это умения и знания радикально разного уровня. Даже в жабе, где все более причесано, volatile имеет ряд неявных особенностей. В сях, с их низким уровнем, этих особенностей масса(какой компилятор, какая архитектура?).
E__>А теперь вопрос: если человек нормально отвечает и рассказывает все нюансы при использовании volatile, стоит ли его грузить унылыми вопросами про переворот строки и прочим? Может ли человек, понимающий, как работает этот барьер памяти на уровне разных архитектур, не понимать указателей? Или чего-то еще?
Так в этом же самая соль. Спрашиваем у человека — чему равен размер struct {void *member}.
Один выпаливает: "4 байта". Второй говорит: "зависит от архитектуры, на x86 4 байта, на amd64 — 8".
Третий спрашивает: "а #pragma pack ? а настройки компилятора ? не-е, тут не все так просто,
давайте сидеть решать конкретно", четвертый прикалывается: "sizeof (struct)" и т.п.
Пятый молча берет бумажку и сходу пишет шаблонный класс, параметризируемый типом структуры, с
выведением типа, вложенными тайпдефами, воркэраундами и т.п. "Сейчас-сейчас, через полчаса у
нас будет универсальный шаблон для определения размера типа с проверкой в compile time".
Второго и третьего я бы повел дальше, к остальным надо подозрительно присмотреться.
Ну и так далее в том же духе. IMHO на собеседовании не столько важны сами вопросы и даже не
правильные/неправильные ответы на них, сколько реакция и поведение собеседуемого.
Чем больше получится узнать о его подходах, воззрениях, да и вообще узнать как человека, тем лучше.
Давать многочасовые сложные задания — бред. Спрашивать про разворот списка, как и про другие, не
шибко сложные, но требующие логического подхода и воображения вещи — можно и нужно.
Не с целью получить верный ответ, а с целью получить представление о способностях кандидата к
какому-то мышлению, выводам, поискам путей, как он будет выкручиваться, когда поймет, что не
может справиться с задачей, и т.п.
O>Здесь гарантируется, что процессор будет выполнять запись в порядке val1-val2, но никогда не наоборот, O>причем эта гарантия основывается исключительно на особенностях архитектуры, а не на поведении компилятора, O>хотя и оно тоже сказывается, так как он не станет изменять порядок обращения к volatile-данным.
Какой процессор? PowerPC? Alpha? ARM? Разумеется, нет. Здесь гарантируется, что компилятор сгенерирует
инструкции записи сначала для val1, потом для val2, и только. Не нужно особенности архитектуры выдавать
за свойство volatile.
O>И для данного примера не требуется вставлять никаких дополнительных барьеров — ни компиляторных, O>ни особенно хардварных, так как это лишь приведет к дополнительным накладным расходам. O>У нас уже есть барьер в виде того, что комбинация запись-запись [просто так] не переупорядочивается.
Барьера нет, если нужен именно такой порядок, следует вставить wmb. А уже его реализация для данной архитектуры
может быть пустой, что избавляет от оверхеда.
V>>Еще раз, интерпретация должна быть такой: "неявно ставит слабый барьер компилятора".
O>Что значит "слабый" ? Неспособный влиять на hardware reordering ? O>Ок. Сможете привести пример кода для x86 или amd64 а-ля тест Деккера, который бы доказал, O>что запись или чтение volatile-данных не сказывается на hardware reordering ? Уверен, что нет.
Уже говорил: слабый потому, что влияет только на volatile переменные. Все барьеры компилятора не влияют на
hardware reordering заранее известным способом, поэтому никаких предположений лучше не делать.
Пример кода вы привели сами — посмотрите на ассемблерный выхлоп, там не будет инструкций ни явно влияющих на
реордеринг (вроде mfence), ни влияющих неявно (вроде cmpxchg).
Кстати, попробуйте написать лок Деккера с использованием только volatile или других барьеров компилятора — для
мультипроцессорных систем не получится, т.к. там понадобятся барьеры памяти, которые volatile не обеспечивает.
O>Приведите. Только не надо возвращаться к архаичным 80486.
Например, линейка GeodeGX/LX/NX. Последний построен на базе атлона, поэтому, в отличие от первых двух, не
поддерживает store reordering.
O>Вот только чтение или запись в память выполняется процессором, а не компилятором, а операции O>доступа к памяти сказываются на переупорядочивании и могут его ограничивать. О чем я тут и талдычу.
А могут не ограничивать. Поэтому утверждение, что volatile всегда ограничивает реордеринг и ставит барьер
памяти — ложно.
O>Для программы не имеет значения откуда она получила данные — реально из памяти или из кэша. O>До тех пор, пока остальные процессоры "видят" то же самое значение через различные механизмы O>синхронизации, в том числе через когерентность кэша. С другими архитектурами я не работал, O>так что про них сказать не могу.
В мире полно процессоров, где когерентность кеша намного слабее, чем у интела. Но тут согласен, для
большинства потребительских (сиречь х86) на это можно не обращать внимания.
Здравствуйте, okman, Вы писали:
O>Какая еще путаница ? Я ведь конкретно написал.
Давайте проясним один вопрос. У меня сложилось впечатление, что все что вы пишете относится исключительно к случаю "Windows + майкросовтовской компилятор + x86". Я правильно понял?
Здравствуйте, StanislavK, Вы писали:
SK>Здравствуйте, okman, Вы писали:
O>>Какая еще путаница ? Я ведь конкретно написал. SK>Давайте проясним один вопрос. У меня сложилось впечатление, что все что вы пишете относится исключительно к случаю "Windows + майкросовтовской компилятор + x86". Я правильно понял?
Даже для такой связки явный барьер памяти нужен, но придется еще сильнее углубиться в архитектуру интеловских процессоров.
В SSE2 появились инструкции загрузки/сохранения с помощью non-temporal hint в обход всех кешей (они быстрые
и не засоряют кеш). Реализуется через write-combining протокол работы с памятью. Поэтому, хотя такие инструкции
записи и не будут переупорядочены, переменные val1 и val2 для других процессоров могут обновиться в противоположном
порядке, т.е. эффект аналогичен переупорядочиванию инструкций. Можете представить себе отладку подобных багов. Так что
если алгоритм требует барьера памяти — его нужно ставить явно, а не полагаться на volatile и знания конкретной архитектуры.
И раз уж пошла такая пьянка, когерентность кешей инструкций в х86 не обеспечивается, т.е. при работе с self-modifying кодом
(например, вы ваяте JIT) это тоже надо учитывать — одного volatile мало.
Здравствуйте, Eugeny__, Вы писали:
E__>А теперь вопрос: если человек нормально отвечает и рассказывает все нюансы при использовании volatile, стоит ли его грузить унылыми вопросами про переворот строки и прочим? Может ли человек, понимающий, как работает этот барьер памяти на уровне разных архитектур, не понимать указателей? Или чего-то еще?
