Здравствуйте, 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>Через надувание разве что, которым утомил.
Поскольку беседа с вами утратила последние шансы на конструктив, отправлю-ка я вас в игнор недельки на четыре. Удачи в "нумерации видов блокировок".

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

V>>Далее я требую объяснения трижды тобой повторённого "это бред".
V>>Итак?..
S>Что "итак"? В чём вопрос-то?

В ответе одного кадра за свои слова.
Ответить не может, т.е. плевался какашками "просто так", по велению души.
Так и запишем.


S>Почему нельзя обойтись одной операцией Interlocked.CompareExchange? Посмотрите в код хотя бы того же MySQL. Там как бэ делается дофига чего, помимо "одной интерлокед операции".

Я и смотрел, в отличие от тебя.
Для тебя инфа по той ссылке — та самая одноразовая рыбка, которой тебя угостили.
Через единицы дней после прочтения и запаха не останется.
А учиться ловить рыбу тебе лень. ))

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

Задачей же инженера является не просто приобретение знаний в результате исследований, но непосредственное использование добытых знаний в конкретном продукте.
И знаниями, напротив, инженеры в кап.модели экономики делятся крайне неохотно, бо работодатель прямо запрещает.
Ну и, про "обособленности феномена" речи тоже обычно нет — инженер обычно работает над комплексом технических взаимодействующих проблем.

Да, именно поэтому зачастую возникает хорошо заметный разрыв теотеризирования и практики в IT — из-за вакуума знаний на уровне, собсно, реализаций.
И отсылками к некоей литературе, которая целиком и полностью мимо, ты лишь показываешь, что вообще ни черта не понимаешь, где и почему этот вакум обитает, и откуда этот вакуум вообще берётся.
Ну какой в опу вакуум там, где есть литература, ы?

Мне иногда кажется в общении с тобой (с твоими посыланиями нахер DDD, с вопросами "а почему это вдруг пакет о программе знает, а программа о пакете нет?", с твоей неспособностью обсуждать никакие блокировки и вообще межпоточное взаимодействие в принципе), что с тобой надо разговаривать как с ребёнком, т.е. каждое объяснение начинать вообще с 0-ля.
Отсутствуют порой какие совсем базовые представления о том, как всё устроено и работает.

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

Но в оригинальном коде MySQL (там же в статье) всё намного проще — под "глобальным" на таблицу мьютексом делается относительно мало, но зато всё оперирование происходит под одной и той же полной блокировкой таблицы в моменты оперирования её "локами", о как!

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


V>>В других ф-иях состояние может изменяться атомарно, независимо от счётчика.
V>>Иногда, согласно семантике, "произвольное" значение счётчика не требуется, счётчик может вырождаться до одного бита, тогда для прикладной семантики остаётся больше бит.
S>И? Дальше что?

Дальше не надо было бегать.
Был вполне понятный пост:
http://www.rsdn.org/forum/flame.comp/8108421.1

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

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

Поэтому, какие в опу "таблицы", когда речь о реализации неких дисциплин диспетчеризации?
Разве некоему мьютексу требуется "знать" что там с помощью него мутуально-эксклюзивно захватывают? ))

Так и здесь.
Для режимов работы "локов" требовалось сформулировать ТЗ.
А кто там будет эти локи и как использовать — это уже другой уровень.
Я увидел очередные твои зияющие пробелы именно на этом уровне.

Мои попытки вернуть тебя на грешную землю, мол, те вещи, которые ты преподносишь как некие "знания" для юзверя СУБД, для данного уровня являются не более чем ТЗ ты тупо игноришь, т.е. опять не понимаешь, что тебе говорят и почему именно так. Информация классически не задерживается при отсутствии понимания.

В общем, предлагалось ТЗ формализировать и провести его классический анализ.
Это более чем обычный ход работ при проектировании чего угодно.

Пример RO/RW был приведён.
Ни само описание задачи RO/RW, ни его классическая реализация не были приведены по упомянутой там же причине — они общедоступны, т.е. считаем, что оно уже есть в контексте.
Т.е. можно рассматривать отдельные моменты работы предложенной к рассмотрению реализации поверх выталкивающей многозадачности.

Но у меня возникло впечатление, что я разговаривал с забором. ))

Похоже, ты вообще не отдупляешь, что происходило (и должно происходить далее, т.е. не понимаешь общего рисунка).
"Дайте мне сразу код СУБД!" ))

И зачем тебе еще одна рыба?
Через пару дней всё-равно в голове опять пусто будет.


S>В том-то и дело, что в атомарно изменяемой переменной не сохранишь весь список действующих на данный момент блокировок.

Почему ты решил, что надо хранить весь список?
Почему ты вообще пытаешься перескакивать этапы проектирования?

Но т.к. это у тебя уже не в первый раз и ожидалось (тебя легко просчитать) — ответ на этот вопрос был дан заранее: "в атомарной переменной можно хранить признаки наличия действующих блокировок".
Медитируй.


S>А его надо где-то держать и своевременно обновлять — иначе невозможно реализовать ни реентерабельность, ни конверсию локов, ни детектирование дедлоков.

Очередное ЧТД.
Для всего этого не нужны полные списки действующих "локов".
10 действующих локов какого-ти типа равны одному действующему локу этого же типа.


S>Именно поэтому так, как вы пишете, не делает в СУБД никто.

Вот, именно поэтому ты трепло, бо ты понятия не имеешь как пишут СУБД и вообще любые подобные системы.
Из пальца насасывать изволишь.

Да и в любом случае, если тебе охота пообсуждать конкретные структуры данных — так на них надо еще выйти в процессе проектирования.
Выход на структуры данных происходит после устаканивания ролей/сценариев/алгоритмов реализации подсистем.
Т.е. в самую последнюю очередь.
Т.е. пытаешься начать с конца.

Как по мне — наводишь бесполезную суету, судорожно пытаешься показать, что тоже хоть что-то знаешь по теме или хотя бы слышал краем уха.
Да мне похер, вообще-то.
Не интересно — идите бродите, хосподя.

Просто ты ж сам вначале создал вид, что тебе это якобы интересно, ввел в заблуждение, получается.
А теперь "красиво соскочить" не можешь, продолжаешь некрасиво суетиться, лепетать несвязное "а вы видели КАКИЕ там списки???!!!".

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

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

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

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

Т.е. попахивает попыткой "отвоевания" себе "на принципиальном уровне" права разлагольствовать в общем и целом, то бишь ни о чём.
Не прокатило.
Со мной так уж точно.

Сейчас ты тупо RIP как коллега.
Я и так тебе мильон скидок делал все эти долгие годы по понятной причине, хотя как личность ты не заслуживаешь, бо свои комплексы так и не одолел, позволяешь себе их реализацию на коллегах... но, блин, имея за спиной ВО в точных науках, столько лет обитая в IT... неужели не смог за 25 лет подтянуть примерно 2.5 года разницы программ специальностей?