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

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

Отлично.
Далее я требую объяснения трижды тобой повторённого "это бред".
Итак?..


V>>Тпруу, ничего такого ты не пытался никому объяснить, сейчас пытаешься подменить тезис в очередной раз.
S>Именно это и пытался. В ответ на ваши шапкозакидательские утверждения.

Да понятно, что "священную корову пнули". ))
Лишний раз даешь понять, что для тебя обсуждаемое вдиковинку.

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

В общем, есть попытка отделения мух от котлет.
И эта попытка была весьма конструктивной, если бы ты не игнорил поступающую тебе информацию.

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

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

Далее нужна некая ф-ия bool is_compatible_lock(int desired_lock, int locks_in_force_mask), которую включить в прикладной код.

Например, из реального проекта пример кода:

size_t counterValue(size_t counter)
{
    return counter & CounterMask;
}

/// Returns the number of linked shared unresolved tasks.
size_t decrementCounter(size_t volatile & counter)
{
    while(true) {
        const size_t value = counter;

        assert(counterValue(value) >= 1);

        const size_t newValue = (counterValue(value) - 1) | (value & StateBits);

        if(Interlocked::cas(&counter, newValue, value))
            return counterValue(newValue);
    }
}

Тело счётчика обновляется независимо от полей состояния.
В других ф-иях состояние может изменяться атомарно, независимо от счётчика.

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

Сравни этот код со схематичным кодом обновления целевой переменной в "самописном" семафоре, приведённым тебе ранее.
Сравни с кодом MySQL по твоей же ссылке, где делается тупой захват одного мьютекса на таблицу, а примитивы-замки (locks) обслуживаются под одним и тем же мьютексом каждый божий раз.


V>>Ну и, опять поторопимшись здесь тоже косячишь — для составления собсно плана тоже блокировки нужны, на уровень схемы хотя бы.
S>А где я говорил, что блокировки на схему не нужны?

Ты упустил это в рассуждениях, сравнивая блокировки с задачей составления плана.
Честно, я ХЗ как можно сравнивать вкус, допустим, арбуза и борща, зелёное с горячим и т.д.

В общем, практически везде, когда пытаешься рассуждать "у вас тут чушь", оперируя при этом низкоинформативными своими оценочными суждениями.
Подобного рода рассуждения на этом сайте желательно запихать Обаме в тёмное место и не светить ими. ))

Требуется более приближенные к IT вещи:
— постановка и анализ задачи;
— поиск решений (обязательно более одного), анализ найденных решений и выбор из них, возможно синтез новых решений на основе анализа.
Возможен возврат к началу и уточнение задачи, по мере раскрытия подробностей происходящего.

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

Да еще подключешь слишком много личного, замыливая любые попытки количественного оперирования информацией (в т.ч. оперирования представлениями о происходящим на функциональном уровне) — качественными оценками, т.е. оперированием неким "просто мнением", вплоть до совсем трешёвого деления технологий на "плохие" и "хорошие".

Это почему с тобой невозможно адекватно обсуждать ничего касаемого того же дотнета — как только тебе слышится в количественных оценках намек на качественное "плохо" — тут же ловишь клина.


V>>Так не въезжаю во что именно?
S>Не въезжаете в механику работы управления блокировками в СУБД.

Ой, блин, опять Синклер показывает какое он ничтожное брехло.
И опять ты озвучил такое обвинение в адрес оппонента, которое всё-равно раскрыть/показать/доказать никогда не сможешь.

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

Кароч, просто открываешь рот и льёш оттуда тупые гадости обиженного человека, что его держат тут за банального недоучку.
Причём, за неудоучу упоротого, который и не собирается доучиваться. ))

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

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

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

Отлично.
Далее я требую объяснения трижды тобой повторённого "это бред".
Итак?..


V>>Тпруу, ничего такого ты не пытался никому объяснить, сейчас пытаешься подменить тезис в очередной раз.
S>Именно это и пытался. В ответ на ваши шапкозакидательские утверждения.

Да понятно, что "священную корову пнули". ))
Лишний раз даешь понять, что для тебя обсуждаемое вдиковинку.

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

В общем, есть попытка отделения мух от котлет.
И эта попытка была весьма конструктивной, если бы ты не игнорил поступающую тебе информацию.

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

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

Далее нужна некая ф-ия bool is_compatible_lock(int desired_lock, int locks_in_force_mask), которую включить в прикладной код.

Например, из реального проекта пример кода:

size_t counterValue(size_t counter)
{
    return counter & CounterMask;
}

/// Returns the number of linked shared unresolved tasks.
size_t decrementCounter(size_t volatile & counter)
{
    while(true) {
        const size_t value = counter;

        assert(counterValue(value) >= 1);

        const size_t newValue = (counterValue(value) - 1) | (value & StateBits);

        if(Interlocked::cas(&counter, newValue, value))
            return counterValue(newValue);
    }
}

Тело счётчика обновляется независимо от полей состояния.
В других ф-иях состояние может изменяться атомарно, независимо от счётчика.

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

Сравни этот код со схематичным кодом обновления целевой переменной в "самописном" семафоре, приведённым тебе ранее.
Сравни с кодом MySQL по твоей же ссылке, где делается тупой захват одного мьютекса на таблицу, а примитивы-замки (locks) обслуживаются под одним и тем же мьютексом каждый божий раз.


V>>Ну и, опять поторопимшись здесь тоже косячишь — для составления собсно плана тоже блокировки нужны, на уровень схемы хотя бы.
S>А где я говорил, что блокировки на схему не нужны?

Ты упустил это в рассуждениях, сравнивая блокировки с задачей составления плана.
Честно, я ХЗ как можно сравнивать вкус, допустим, арбуза и борща, зелёное с горячим и т.д.

В общем, практически везде, когда пытаешься рассуждать "у вас тут чушь", оперируя при этом низкоинформативными своими оценочными суждениями.
Подобного рода рассуждения на этом сайте желательно запихать Обаме в тёмное место и не светить ими. ))

Требуется более приближенные к IT вещи:
— постановка и анализ задачи;
— поиск решений (обязательно более одного), анализ найденных решений и выбор из них, возможно синтез новых решений на основе анализа.
Возможен возврат к началу и уточнение задачи, по мере раскрытия подробностей происходящего.

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

Да еще подключешь слишком много личного, замыливая любые попытки количественного оперирования информацией (в т.ч. оперирования представлениями о происходящем на функциональном уровне) — качественными оценками, т.е. оперированием неким "просто мнением", вплоть до совсем трешёвого деления технологий на "плохие" и "хорошие".

Это почему с тобой невозможно адекватно обсуждать ничего касаемого того же дотнета — как только тебе слышится в количественных оценках намек на качественное "плохо" — тут же ловишь клина.


V>>Так не въезжаю во что именно?
S>Не въезжаете в механику работы управления блокировками в СУБД.

Ой, блин, опять Синклер показывает какое он ничтожное брехло.
И опять ты озвучил такое обвинение в адрес оппонента, которое всё-равно раскрыть/показать/доказать никогда не сможешь.

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

Кароч, просто открываешь рот и льёш оттуда тупые гадости обиженного человека, что его держат тут за банального недоучку.
Причём, за неудоучу упоротого, который и не собирается доучиваться. ))

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