(no subject)
Nov. 10th, 2011 06:52 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
yigal_sВнезапно осознал, что совсем практически себе не представлял, что оптимизатор может делать, а что не может, работая с константной ссылкой (равно как и с указателем на константу) в С++.
Скажем, если мы будем в цикле локать мютекс из pthreads и проверять значение, на который указывает указатель на константу, далее отпуская мютекс и снова начиная тело цикла с начала -- есть ли у нас гарантия, что мы увидим изменение этого значения из-под другого треда, или же компилятор выпилит все проверки кроме первой?
Вообще-то говоря, такие вещи надо бы знать идеально. Это даже не таинственного мультитредного С++ касается, который вот уже полтора десятка лет живёт без всякой стандартизации, а и вполне обычного стандартизированного однотредного С++, где мы можем из-под выше описываемого цикла вызывать заодно и какую-то внешнюю функцию без аргументов, меняющую значение переменной, на которую у нас есть константый указатель. Надо бы мне это знать. А вот нет. Как-то проскочил мимо, или же знал, но давно позабыл.
Пока-что не нашел этого в стандарте описанным явно, но, судя по всяким косвенным признакам, гарантия такая (о том, что мы разглядим изменение переменной) имеется, и константность типа, на который указывает указатель, не является сама по себе основанием для каких-то дополнительных оптимизаций, которые не могут быть применены к указателю на неконстантный тип (здесь я коварно усмехаюсь).
"не является сама по себе основанием для каких-то дополнительных оптимизаций" -- если у кого-то есть возражения или комментарии по этому поводу, равно как и вообще, буду рад обсудить.
Скажем, если мы будем в цикле локать мютекс из pthreads и проверять значение, на который указывает указатель на константу, далее отпуская мютекс и снова начиная тело цикла с начала -- есть ли у нас гарантия, что мы увидим изменение этого значения из-под другого треда, или же компилятор выпилит все проверки кроме первой?
Вообще-то говоря, такие вещи надо бы знать идеально. Это даже не таинственного мультитредного С++ касается, который вот уже полтора десятка лет живёт без всякой стандартизации, а и вполне обычного стандартизированного однотредного С++, где мы можем из-под выше описываемого цикла вызывать заодно и какую-то внешнюю функцию без аргументов, меняющую значение переменной, на которую у нас есть константый указатель. Надо бы мне это знать. А вот нет. Как-то проскочил мимо, или же знал, но давно позабыл.
Пока-что не нашел этого в стандарте описанным явно, но, судя по всяким косвенным признакам, гарантия такая (о том, что мы разглядим изменение переменной) имеется, и константность типа, на который указывает указатель, не является сама по себе основанием для каких-то дополнительных оптимизаций, которые не могут быть применены к указателю на неконстантный тип (здесь я коварно усмехаюсь).
"не является сама по себе основанием для каких-то дополнительных оптимизаций" -- если у кого-то есть возражения или комментарии по этому поводу, равно как и вообще, буду рад обсудить.
no subject
Date: 2011-11-14 04:22 pm (UTC)на это у меня есть два ответа - простой и сложный.
простой заключается в том, что с тех пор, как опубликован спек на модель доступа к памяти на i86 (вроде всего как 3-4 года назад), ты можешь юзать интерлоки только там, где они реально нужны. Скажем, посмотри atomic в С++ - он как раз дает "все возможные" мембары при доступе, начиная от совершенно "relaxed" вплоть до "sequentially consistent".
Я, между прочим, не думаю, что эти atomic написаны правильно в смысле перспектив их использования для написания идеального кроссплатформенного кода, но во всяком случае, при работе под конкретную платформу, ты можешь четко решать, какой уровень сериализации заказать при доступе.
Другое дело, что надо прокачать скиллзы, чтобы писать корректный код на минимально необходимой сериализации доступа к памяти. Я вот, например, не прокачал до сих пор, но понемножку над этим работаю.
А вообще, по-моему, не надо бояться тяжелых интерлоков. Всё равно мы не умеем писать хороший код под тяжелый мультитред, ну а под лёгкий, там где бегут 4-8 ядер, пожалуй, ничего страшного от пары-тройки лишних интерлоков не слуыится.