Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, Sinclair, Вы писали:

V>>>Прямой речью спрашиваю — как ты понимаешь фразу "одна интерлокед-операция"?
V>>>С учётом двухкратных отсылок к циклу обновления, плюс первый раз когда его привели (и по наивности посчитали, что достаточно).
S>>Я понимаю под этим однократное выполнение Interlocked.CompareExchange. Что, в общем-то, логично, с учётом того, что упоминалась эта одинокая операция в контексте отсутствия конфликтов.

V>Отлично.
V>Далее я требую объяснения трижды тобой повторённого "это бред".
V>Итак?..
Что "итак"? В чём вопрос-то? Почему нельзя обойтись одной операцией Interlocked.CompareExchange? Посмотрите в код хотя бы того же MySQL. Там как бэ делается дофига чего, помимо "одной интерлокед операции".

V>Например, тебе подсказывалось, что битовое поле атомарно-изменяемой переменной можно поделить на участки.
V>Допустим, у тебя 4 вида блокировки, т.е. 4 режима доступа к некоей странице/таблице (не важно, эти прикладные подробности зависят от принятой схемы организации и хранения данных), в атомарной переменной ведь не сохранишь весь список действующих в данный момент блокировок, но сохранишь какой-либо признак, достаточный для атомарного оперирования.
V>Тело счётчика обновляется независимо от полей состояния.
V>В других ф-иях состояние может изменяться атомарно, независимо от счётчика.
V>Иногда, согласно семантике, "произвольное" значение счётчика не требуется, счётчик может вырождаться до одного бита, тогда для прикладной семантики остаётся больше бит.
И? Дальше что? В том-то и дело, что в атомарно изменяемой переменной не сохранишь весь список действующих на данный момент блокировок. А его надо где-то держать и своевременно обновлять — иначе невозможно реализовать ни реентерабельность, ни конверсию локов, ни детектирование дедлоков. Именно поэтому так, как вы пишете, не делает в СУБД никто.
V>Сравни этот код со схематичным кодом обновления целевой переменной в "самописном" семафоре, приведённым тебе ранее.
Никакого толку нет ни с того кода, ни с этого.
V>Сравни с кодом MySQL по твоей же ссылке, где делается тупой захват одного мьютекса на таблицу, а примитивы-замки (locks) обслуживаются под одним и тем же мьютексом каждый божий раз.
Сравнил. Ничего общего нет. Ну, то есть код под одним мьютексом плохой — в статье подробно описаны причины. Предложенный взамен код, который работает получше, тоже ничего общего с вашим кодом не имеет даже близко.

V>Ты упустил это в рассуждениях, сравнивая блокировки с задачей составления плана.
Где я сравнивал блокировки с задачей составления плана? Опять бредите.

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

Ну, как я и ожидал, все технические вопросы были скипнуты.
V>Но построить из себя грамотного охота, верно?
Вижу, что охота.
V>Через надувание разве что, которым утомил.
Поскольку беседа с вами утратила последние шансы на конструктив, отправлю-ка я вас в игнор недельки на четыре. Удачи в "нумерации видов блокировок".