yigal_s | (no subject)

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

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

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

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

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

Flat | Top-Level Comments Only

слушай, а в чем сокровенный смысл того, что у критических секций частичная 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. это как раз тот случай.