yigal_s | (no subject)

(no subject)

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

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

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

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

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

Flat | Top-Level Comments Only

> то evaluation of an expression очевидно должно быть на основании этих самых свежих данных. есть другое мнение?

Разумеется :-)

чтение неволатальной переменной не есть сайд-эффект
вычисление выражения, если оно не сопровождается изменением объектов памяти не есть сайд-эффект
выход из оператора цикла не есть сайд-эффект :-)

наконец, я что-то пока не заметил, где написано, что "evaluation of an expression очевидно должно быть на основании этих самых свежих данных", но, как видишь, я и при наличии этого утверждения вполне вроде б аргументированно, показываю, что оператор цикла не закочится.

Кароче, кончай заниматься казуистикой. (Это я себе))) Стандарт 99&03 сдох, в новом стандарте всё чуток по другому, какой смысл заниматься толкованием этих текстов? - всё равно не ты не я не являемся специалистами по чтению подобного материала.

Хотя, вот если ты имеешь какие-то опровержения моих конкретных заявлений по С++ на основании стандарта, это было б небезынтересно рассмотреть.

Да, разумеется, и spinlock на нем не напишешь. Но заметь, что по факту это никого особо не колыхало и как в unix, так и в windows можно было писать вполне рабочие программы (учитывая определенное сотрудничество разработчиков библиотек синхронизации и разработчиков компиляторов). Ну да, совершенно вне стандарта, ну так и что?

в соответствии с вышеизложенным спеком, функция f1 может никогда не окончиться. )))

хочешь казуистики, гад? держи: функция обязана завершиться независимо от работы оптимизатора, иначе не завершится программа и не сможет вернуть exit code, а это observable behavior.

Не говоря уже о том, что нарушается та самая sequence of reads and writes to volatile data and calls to library I/O functions.

Но заметь, что по факту это никого особо не колыхало и как в unix, так и в windows можно было писать вполне рабочие программы (учитывая определенное сотрудничество разработчиков библиотек синхронизации и разработчиков компиляторов). Ну да, совершенно вне стандарта, ну так и что?

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

> держи: функция обязана завершиться независимо от работы оптимизатора, иначе не завершится программа и не сможет вернуть exit code, а это observable behavior.

> Не говоря уже о том, что нарушается та самая sequence of reads and writes to volatile data and calls to library I/O functions.

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

* столько всего лично нами написано

Говори плз за себя.

Вот мой пост от 2003-го года
http://ru-programming.livejournal.com/11316.html

А на ixbt меня за дискуссию по этой же теме просто забанили )))

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

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

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

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

офф - про 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. это как раз тот случай.

Flat | Top-Level Comments Only