yigal_s | (no subject)

Внезапно осознал, что совсем практически себе не представлял, что оптимизатор может делать, а что не может, работая с константной ссылкой (равно как и с указателем на константу) в С++.

Скажем, если мы будем в цикле локать мютекс из pthreads и проверять значение, на который указывает указатель на константу, далее отпуская мютекс и снова начиная тело цикла с начала -- есть ли у нас гарантия, что мы увидим изменение этого значения из-под другого треда, или же компилятор выпилит все проверки кроме первой?

Вообще-то говоря, такие вещи надо бы знать идеально. Это даже не таинственного мультитредного С++ касается, который вот уже полтора десятка лет живёт без всякой стандартизации, а и вполне обычного стандартизированного однотредного С++, где мы можем из-под выше описываемого цикла вызывать заодно и какую-то внешнюю функцию без аргументов, меняющую значение переменной, на которую у нас есть константый указатель. Надо бы мне это знать. А вот нет. Как-то проскочил мимо, или же знал, но давно позабыл.

Пока-что не нашел этого в стандарте описанным явно, но, судя по всяким косвенным признакам, гарантия такая (о том, что мы разглядим изменение переменной) имеется, и константность типа, на который указывает указатель, не является сама по себе основанием для каких-то дополнительных оптимизаций, которые не могут быть применены к указателю на неконстантный тип (здесь я коварно усмехаюсь).

"не является сама по себе основанием для каких-то дополнительных оптимизаций" -- если у кого-то есть возражения или комментарии по этому поводу, равно как и вообще, буду рад обсудить.

Flat | Top-Level Comments Only

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

я даже знаю, благодаря кому :) вот вопрос и возникает - как корректно писать без тяжелых интерлоков.

офф - про keyed events (http://locklessinc.com/articles/keyed_events/) читал?

* вот вопрос и возникает - как корректно писать без тяжелых интерлоков

на это у меня есть два ответа - простой и сложный.

простой заключается в том, что с тех пор, как опубликован спек на модель доступа к памяти на i86 (вроде всего как 3-4 года назад), ты можешь юзать интерлоки только там, где они реально нужны. Скажем, посмотри atomic в С++ - он как раз дает "все возможные" мембары при доступе, начиная от совершенно "relaxed" вплоть до "sequentially consistent".

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

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

А вообще, по-моему, не надо бояться тяжелых интерлоков. Всё равно мы не умеем писать хороший код под тяжелый мультитред, ну а под лёгкий, там где бегут 4-8 ядер, пожалуй, ничего страшного от пары-тройки лишних интерлоков не слуыится.

про keyed events не читал, спасибо за ссылку

* я даже знаю, благодаря кому :)

так я и говорю - это было моё решение, и я считаю его на тот момент и при том контингенте программистов - правильным ;-)

слушай, а в чем сокровенный смысл того, что у критических секций частичная lazy initialization? чего микрософт этим добивается кроме последующего описанного по ссылке забега по граблям?

очевидно на handles экономили, non-paged pool соответственно и всякое такое.

вот, нашлось:
http://www.bluebytesoftware.com/blog/PermaLink,guid,db9f8f5b-8d1d-44b0-afbd-3eadde24b678.aspx

странное решение. программа всё равно со временем имеет шансы постепенно заллоцировать все events, переполнить таблицу хендлов и упасть.

какой-то очень грязный патч, непонятно, как они могли подобное зарелизить в win2000

мы такого идиотизма не писали, если ты помнишь

странное решение. программа всё равно со временем имеет шансы постепенно заллоцировать все events, переполнить таблицу хендлов и упасть.

пишут же, что собрали статистику, уж наверное толк был.

ты наверное не понял - аллокация происходит in response to the first contended acquire, то есть захват свободной critical section до поры до времени происходит бездвоздмездно, то есть даром.

очень может быть, что "на тот момент и при том контингенте программистов" ;) это была ни фига себе оптимизация.

да вроде, именно так я понял.

это ты, вродь, не понял, что со временем все critical sectionы зааллоцируют свои events. т.е. статистика тут может быть такая: "в среднем проблематичная программа навернётся через 15 суток интенсивной работы - офигительно долго, давайти это имплементируем!"

тогда можно уж и память каждой программе преаллоцировать сразу гиг или два, все равно ведь может понадобиться?

понимаешь, есть такое мнение, что lazy resource acquisition leads to better scalability. это как раз тот случай.