Здравствуйте, Ночной Смотрящий, Вы писали:

I>>Я разок, с целью демонстрации, "заварил" воду без кофе в таком автомате и дал людям прочувствовать "аромат". Чистая бутилированая вода, которую вкусно пить, стала жижей с неприятным запахом.
I>>Трудно ожидать нормального кофе.

НС>Ну а Синклера, как видишь, устраивает вообще Nespresso.

Процитирую себя

Дома вместо 400 порций в день будет 400 порций в год. Соответсвенно автомат не ушатывается так быстро. А еще и чистится гораздо чаще, чем раз в год. И кофе можно засыпать мелкими пакетами, тогда он всегда самый свежий.

То есть, если Синклер не готовит по 400 порций в день, чистит от накипи, капсулы берет свежие, а не прошлогодние, то вполне себе сгодится.

Вот, например, где можно набрать свежих капсул https://theweldercatherine.ru/catalog/kapsuly/
У них еще и лимитки бывают, там вообще бомба, от одного аромата ошалеть можно.

Здравствуйте, Ночной Смотрящий, Вы писали:

I>>Собственно, такое бывает, но только в тех случаях, если у кого то есть желание ухаживать за автоматом. Как правило, про все это забывают.

НС>Не знаю как у вас в РБ, но у нас ухаживают. Конкретно в Ярче, к примеру, поток народа такой, что они автомат несколько раз в день чистят и заправляют. А вот в каком нибудь ларчике непонятно, даже если там суперрожковая кофеварка установлена.

На счет "ухаживают" это вероятно в конретных местах.

I>> Тонкости приготовления как раз важны.

НС>Или нет.

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

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

I>> Правильный помол под конкретное зерно позволяет получить или упустить те самые вкусы и ароматы.

НС>Да да, я помню. Надо много лет жрать кофе литрами чтобы научиться, я помню.

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

> Только это не массовый рынок.

Это давно часть массового рынка, те самые "кофейни третьей волны".

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Почему?
Потому, что профессионал — это тот, кто разбирается в процессе. См. например https://ligabarista.ru/for-professionals/
А автомат позволяет любой бабе Клаве из студенческой столовой нажимать на кнопку "капучино".

НС>У тебя дома ведь не "какая-нибудь двух-четырёх рожковая Лавацца", верно? Тем не менее кофе оттуда тебя устраивает.
Рожковая машина у меня тоже есть. Я её забросил, т.к. она деградировала за годы использования. Капсульной машинке — чуть больше года, и пока что она работает нормально.
Нужно учитывать, что работает она на двух человек, т.е. выдаёт от 2 до 5 чашек кофе в сутки. При этом я её аккуратно промываю, и заправляю исключительно бутылированной водой.
Капсулы и молоко выбираю на свой вкус — перебрал полтора десятка видов капсул и не то три, не то четыре вида молока.
Автомат общего доступа выдаёт от нескольких десятков до нескольких сотен кружек в сутки, заправляется неизвестно чем, и обслуживается неизвестно как.
Например, машины, которые ставили к нам в офис (профессиональные автоматы от Saeco), начинали варить стрёмный кофе (при тех же зёрнах и прочем) за 6 месяцев, а убивались окончательно примерно за полтора года.

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

НС>>Почему?
S>Потому, что профессионал — это тот, кто разбирается в процессе.

Речь про кофеварку, а не про баристу.

S>А автомат позволяет любой бабе Клаве из студенческой столовой нажимать на кнопку "капучино".

И поэтому кофемашины, рассчитанные на профессиональное применение нельзя называть профессиональными?
Профессиональные кофемашины это не те, к которым требуется профессиональный бариста, а те, которые способны без поломок годами заваривать по сотне чашек в день и более. Никакого оксюморона здесь нет.

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

НС>>Не знаю как у вас в РБ, но у нас ухаживают. Конкретно в Ярче, к примеру, поток народа такой, что они автомат несколько раз в день чистят и заправляют. А вот в каком нибудь ларчике непонятно, даже если там суперрожковая кофеварка установлена.
I>На счет "ухаживают" это вероятно в конретных местах.

Именно это я и написал.

I>>> Тонкости приготовления как раз важны.
НС>>Или нет.
I>Здесь как в шахматах — нет такой партии, которую нельзя было бы слить. Любое самое наипрекраснейшее зерно можно опаскудить кривым приготовлением.

В случае кофе-машины это сделать довольно сложно. Вот разве что положить болт на нормальное обслуживание.

I>Не надо литрами. Нужно потренироваться с хорошим баристой.

Простой вопрос — зачем?

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>Не знаю как у вас в РБ, но у нас ухаживают. Конкретно в Ярче, к примеру, поток народа такой, что они автомат несколько раз в день чистят и заправляют. А вот в каком нибудь ларчике непонятно, даже если там суперрожковая кофеварка установлена.
I>>На счет "ухаживают" это вероятно в конретных местах.

НС>Именно это я и написал.

Тогда при чем здесь РБ?

НС>В случае кофе-машины это сделать довольно сложно. Вот разве что положить болт на нормальное обслуживание.

С кофемашиной можно положить болт, что чаще всего и происходит. Далее, подстройка помола, вещь крайне важная. Всё зависит от вкуса того, кто это делает и его навыков. Запороть здесь легче легкого.
Потом есть качество и температура воды, время пролива. Эти вещи тоже влияют очень сильно.

Например, американо из автомата часто это доппио или лунго когда пролив увеличивается вдвое-втрое
То есть, если автомат не умеет делать именно американо, то его эмуляция даёт слишком крепкий, перевареный, с кисло-горьким вкусом.
Собственно, американо варится как эспрессо, только потом добавляем чистую воду в кофе, или кофе в чистую воду. Разница будет только в пенке. А автомат будет проливать 100-150мл через таблетку, и тогда вымываются все вещества, которых в чашке вообще быть не должно. Отсюда и проблемы со вкусом.

I>>Не надо литрами. Нужно потренироваться с хорошим баристой.

НС>Простой вопрос — зачем?

Что бы вкус, аромат и послевкусие было. Нахрена пить кофе если не вкусно?
Хочешь хлебать абы штырило — купи кофеин в таблетках, эффект будет примерно в 10 раз дешевле.

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

НС>>Именно это я и написал.
I>Тогда при чем здесь РБ?

Ну ты же про РБ рассказывал когда писал про то что за машинами не ухаживают. В моей — ухаживают. Где вручную, и я регулярно это наблюдаю, а где совсем уж навороченные машины сами себя промывают периодически.

I>>>Не надо литрами. Нужно потренироваться с хорошим баристой.
НС>>Простой вопрос — зачем?
I>Что бы вкус, аромат и послевкусие было. Нахрена пить кофе если не вкусно?

Да нет, его вкусно и без обучения со стороны профессионального баристы.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>Именно это я и написал.
I>>Тогда при чем здесь РБ?

НС>Ну ты же про РБ рассказывал когда писал про то что за машинами не ухаживают. В моей — ухаживают.

В основной массе и у вас никто не ухаживает.

I>>Что бы вкус, аромат и послевкусие было. Нахрена пить кофе если не вкусно?

НС>Да нет, его вкусно и без обучения со стороны профессионального баристы.

Это ж не всем вкусно Большинство как раз таки уверены, что кофе должен быть крепким и горьким, и всякие оттенки, нотки, ароматы и послевкусия ни разу то и не пробовали.
Кофе имеет сложный состав. Такие напитки сходу понятны только тем, у кого довольно богатый вкус и хорошее обоняние.
А остальные из всего, что там есть, чувсвтвуют только сам кофе.
На самом же деле если в кофе вкус только кофе и ничего больше, то это называется "пустой вкус" и это негативная характеристика.

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

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

НС>>Ну ты же про РБ рассказывал когда писал про то что за машинами не ухаживают. В моей — ухаживают.
I>В основной массе и у вас никто не ухаживает.

Статистику сам собирал?

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>Ну ты же про РБ рассказывал когда писал про то что за машинами не ухаживают. В моей — ухаживают.
I>>В основной массе и у вас никто не ухаживает.

НС>Статистику сам собирал?

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

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

И в сетевых кофейнях автоматы вымерли. Тоже ведь неспроста. Ладно бы в тех, что третьей волны. А сетевым сам бог велел автоматы использоват. Однако эти времена прошли.

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

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

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

V>Будем разгребать:
V>Синклер:
V>- Неадекватное решение — реализация набора видов блокировок в СУБД через самописанный семафор, поддерживающий отрицательные значения счётчиков.
V>Я:
V>- твоё утверждение ложно, бо в СУБД широко используют именно самописные семафоры.
Ну разве можно так бессовестно передёргивать? Все ходы записаны.
Я вас просил привести решение задачи — вы начали с описания некоего решения на основе семафора; затем оговорились, что это решение — плохое, поэтому нужно добавить ещё один семафор, впрочем это решение тоже плохое, поэтому нужно использовать пользовательские очереди задач.
При этом изо всего этого ряда решений код вы привели только для первого, и то неполный, а в стиле "вот вам int main(){}, остальное впишите между фигурными скобками".
Я не утверждаю, что вообще применение каких-либо "самописанных семафоров" плохо. Я говорю, что конкретно ваше решение, предложенное в этой ветке — плохое.
V>Синклер:
V>- нет, блокировка строки и блокировка страницы делается через разные ресурсы, а не через один семафор.

V>Я:
V>- а как соотносятся твои "разный" (в плане экземпляров) и "самописный"?
Очень просто. Я пытаюсь вернуться к мифической "одной interlocked операции", которой было достаточно для сканирования таблицы.
(Уже начинаю подозревать, что речь шла о глобальном семафоре, который, по-вашему, является единственным средством достижения истинного ACID. Нет, такая СУБД будет катастрофически неэффективна на практике, независимо от того, компилируются ли планы запросов статически.)
Пока что вам никак не удаётся показать эту операцию. В основном — потому, что вы бегаете от вопросов про код, отделываясь общими рассуждениями про последовательность решения задач и отсылками к теории СМО.
Интересует не теория, а практика.


V>- и почему "блокировка" делается через "ресурсы"? ))
Нужно же как-то называть то, что мы захватываем и отпускаем. Общепринятое название — просто lock, но у вас какая-то беда с пониманием термина "блокировка".

V>В общем, просьба не применять пока мест просто термин "блокировка", бо ты используешь его неверно уже десяток постов подряд.
Ещё раз умоляю — откройте ссылку на википедию, которую я вам дал, и прекратите кривляться.

V>Если нет — вот одна из первых ссылок в гугле, просто прочти первый абзац, там сходу понятно, что принято называть "ресурсом" в СМО:
V>https://cyberleninka.ru/viewer_images/16416395/f/1.png
Ну прикольно. Вы даже не обратили внимания, что определения термина "ресурс" в вашем источнике нет. Просто нечто, что необходимо для выполнения заявки.
Ок, можно отбросить этот термин и пользоваться только общепринятым термином "блокировка" из мира СУБД. Ссылку на его определение я вам дал.
Если же мы вернёмся в мир СУБД, то в нём "ресурсом" называется некоторый элемент базы данных — строка, страница, таблица, индекс, key range, обьект схемы, вся база данных и т.п.

V>Чтобы дойти до операции блокировки строки, ты должен сначала пройти уровень блокировки страницы.
В общем случае нет. Просто альтернатива настолько неэффективна, что в большинстве реализаций перед захватом блокировки на "кусочек" композитного ресурса делается транзитивный захват intent lock-ов на все вышестоящие ресурсы в иерархии.

V>Т.е. не заблокировать страницу, но "отметиться" на каком-нить примитиве сигнализации уровня страницы, и, отметившись удачно, запретить конкурентным задачам блокировать страницу. Т.е., shared-владение ресурсом запрещает блокировку ресурса (т.е. запрещает монопольное овладение ресурсом, а не производит это овладение, как может показаться из твоей ошибочной терминологии), т.е., чтобы заблокировать страницу, небходимо будет дождаться освобождения всех shared-владений.
Ещё раз порекомендую вам прочитать общепринятое определение термина "блокировка" применительно к СУБД. Оно гораздо удобнее, потому что без него придётся мучиться с многословными формулировками.
Вот к примеру, то, что вы написали выше "пройти уровень блокировки страницы" — не имеет чёткого смысла. Вам приходится выкручиваться при помощи конструкции "попытаться запретить конкурентным задачам блокировать страницу".
А в мире СУБД просто говорят "транзакция захватывает intent exclusive lock на страницу", и всем всё понятно.

V>Хотя ни о каком прикладном отношении RO-RW речь не идёт, речь идёт только о shared, либо монопольном владении, просто при shared-владении безопасны конкурентные чтения, вот и всё кино. Но всё это уже уровень прикладной семантики, т.е. интерпретирования состояний неких переменных, изменяемых атомарно.
Совершенно верно. Поэтому в мире СУБД про читателей и писателей говорить не принято (в отличие, скажем, от мира параллельного программирования, где всё называют именно так (тыц, тыц, тыдыц). А принято так и называть — shared lock и exclusive lock.

V>В данном случае у некоей простейшей СМО (или простейшей такой подсистемы) есть всего два состояния — shared и exclusive.
V>Как обыграть эту пару состояний — я рассказал более чем доступно, ИМХО.
Ну, для начала, там, конечно же, не пара состояний . Состояний там примерно 2^32- в зависимости от того, ограничиваем ли мы максимальное количество одновременных читателей.

Вы привели неполную и неудачную реализацию одного из способов обыграть эту "пару состояний". Даже в википедии приведено ещё два.
В реальных СУБД помимо shared и exclusive применяют update lock, который уже совсем сложно описать одной фразой вроде "запретить конкурентным задачам блокировать страницу".
Кроме того, нужна ещё и реентерабельность, которую ваше решение не обеспечивает и близко, а также умение "апгрейда" блокировки с shared в exclusive. Этого у вас тоже нет.

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

V>Не зря я в самом начале предложил абстрагироваться от идентификаторов блокировок, а просто пронумеровать их, связав в иерархию, чтобы не засорять моск ненужной информацией.
Ну так я уже неделю жду, пока вы "пронумеруете" идентификаторы блокировок. Хотя бы для ровно одной гранулярности, и простой системы shared/update/exclusive, с общепринятой матрицей совместимости.

V>Стадия анализа задач, про которую я уже совсем не скромно намекаю который пост подряд, должна дать тебе отображение прикладных требований на выбранную схему СМО, адекватную поставленной задаче, включая графы переходов, если состояний более одного.
Эта стадия пройдена задолго до меня. А вам, прежде чем бросаться закидывать шапками хорошо известную проблематику, стоило бы всё же почитать какие-то основы. Даже учебника пользователя СУБД достаточно для того, чтобы понять, как именно обеспечиваются различные уровни изоляции, включая serializable, при помощи различных протоколов синхронизации.

V>И да, просьба заканчивать буксовать на "единственном семафоре", бо в подробном описании различных алгоритмов RO-RW блокировки ключевой семафор я называл целевым, но никогда не было речи о том, что один семафор может обслужить разные уровни иерархии, если есть такая потребность в разных уровнях. Один он будет на своём уровне.
Речь была о том, что table scan должна обслужить единственная interlocked переменная. Булшит про СМО появился позже, в попытках отвлечь рассуждение от кода.

V>К тому же, достаточно того, что упоминался "турникет" — а это семафор со счётчиком 1, где "турникетом" его делает способ оперирования этим семафором. Т.е. уже минимум два семафора. И еще требуется сериализация писателей, если есть желание решить проблему голодания писателей в случае, когда мы не управляем задачами, а пользуем семафоры уровня ОС — уже 3 семафора. И это только для разруливания проблематики совместного или монопольного доступа к одному ресурсу.
Вот видите, как здорово. Вижу, у вас начинает появляться понимание, что одной interlocked инструкцией мы никак не обойдёмся.

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

V>И я уже напоминал, что различные уровни изоляции достигаются не только и не столько за счёт блокировок, а чаще за счёт алгоритмов, растущих из банального COW.
V>Т.е., на некоторых уровнях изоляции конкурентные чтения и даже транзакционная запись может быть, но совершенно без эксклюзивных блокировок "ресурсов", как тебе такое?
Такое — плохо. Недаром в стандарте ANSI нет такого уровня изоляции, при котором можно обойтись без эксклюзивных блокировок.
И, кстати, версионников, которые бы при записи обходились без эксклюзивных блокировок, в природе тоже не существует.

V>А недефолтные алгоритмы — сплошное ноу-хау, увы.
V>И почему так — именно тебе не так давно рассказывал уже.
А, вот и секретность пожаловала в студию.


V>Пфф, очередной культурный шок.
V>Коду вообще требуется, чтобы его кто-то писал.
А то.

V>Выглядит как когнитивный диссонанс по причине "само не работает".
V>Т.е., на уровне мозжечка привык рассуждать в духе "с неба упало и само работает", вот до чего дотнет доводит. ))
Вижу, я плохо объяснил вам тему обсуждения, т.к. вы неверно интерпретируете мои вопросы. Попробую ещё раз объяснить: у меня нет проблемы с пониманием того, как устроена механика управления блокировками в СУБД.
И сомнений в том, что она поддаётся реализации, тоже нету. В конце концов — у нас же есть готовые примеры, многие из которых опубликованы в исходниках.

Я просто пытаюсь оценить затраты на эту механику при исполнении реальных запросов. Чтобы эти затраты оценить, нужно хотя бы примерно себе представлять, как всё это устроено внутри.
Когда я говорю "там сложнее, чем вы пишете", то сложно не означает "непонятно". Сложно означает "вычислительно сложно", т.е. то, что выглядит с т.з. диаграммы на доске как "захват блокировки на строку", внутри реализуется как множество инструкций, часть из которых требуют синхронизации (хотя бы через interlocked). А вы делаете совершенно бредовые утверждения про вот эту вычислительную сложность, и ещё и ухитряетесь с менторским видом высказывать не относящиеся к делу банальности.

V>Только в твоём случае этот феномен доходит до крайности: "обычные люди это сделать не смогли бы, такие как я или любые мои собеседники в интернете".
С чего вы взяли? Вы берётесь показывать решение — и сразу сливаетесь, как только речь заходит о коде. Как, впрочем, и более-менее всегда. Начиная от вычисления 2d-фильтров, и заканчивая планами запросов.
Про способности "обчных людей" я ничего не предполагаю — я всего лишь хочу увидеть код, о котором вы так смело рассуждаете.

V>Но ты же не мог всерьёз просить меня ответить тебе работающими исходниками полноценной СУБД? ))
Достаточно умозрительного кода, иллюстрирующего основные тезисы.

V>С херна ли эффективнее существующих?
V>Кто тебе такое обещал?
Вот это поворот! Мы же как раз начали с построения сервера приложений, совмещённого с СУБД, для максимизации эффективности: https://rsdn.org/forum/flame.comp/8103984.1

Автор: vdimas
Дата: 01.10.21

V>Обсуждение возникло по причине того, что ты злостно путаешь уровни изоляции и "блокировки".
Я один раз с недосыпа оговорился. А вот у вас пока что затруднения и с пониманием того, что такое ACID, и с уровнями изоляции. С иерархией блокировок, я вижу, наступает понимание.

V>А будучи реализованным через ручное управление заявками, можно подключать наработки из СМО — они туда сам просятся и так, вообще-то, и поступают при разработке подобных систем сложных диспетчеризаций заявок.
Ну, про ручное управление тема пока что не раскрыта.

V>Твоё зацикливание на СУБД говорит лишь о том, что ты не понимаешь сам этот класс задач.
IP-телефония, на фоне СУБД, с точки зрения разделяемых ресурсов — так, детский лепет на лужайке.

V>Еще тебе говорилось, что вместо "различных видов блокировок" (как ты рассуждал в начале этой беседы), стоит оперировать не их именами собственными, а достаточно рассматривать их нумерованную иерархию, бо на каждом уровне иерархии в плане отношений с низлежащим слоем в СУБД соблюдается строгое подобие от уровня выше.
Да не сможете вы уложить update/exclusive/shared ни в какую нумерованную иерархию. Вы по прежнему путаете гранулярность блокировок и их виды.
То, что вы описываете — и есть те самые intent блокировки, которых по-вашему не существует. И (сюрприз-сюрприз), можно обходиться и без них! Вот только тогда код захвата крупногранулярной блокировки становится громоздким и дорогостоящим.

V>СМО — это не абстрактные рассуждения, а вполне конкретные, и сразу же было сказано почему — так УДОБНЕЙ.
Удобней чем что? Чем принятая в мире СУБД классификация блокировок? Ну-ну.

V>Да, просимулировать происходящее можно и на обычных семафорах, в т.ч. используя код того полусамописного семафора, который я дал, т.к. при симуляции обычно не интересует быстродействие эмулятора, интересует происходящее в количественном выражении, т.е., где, какие, сколько операций, какова вероятность/статистика развития тех или иных сценариев из большого комбинаторного их сочетания и т.д. и т.п.
Что именно вы предлагаете просимулировать и зачем? Убедиться, что ваша реализация падает на простейших сценариях вроде update table1 set field1 = 0 where field2 = 0?


V>И?
V>Одна на таблицу.
V>До этого одна на базу.
V>До этого одна на схему.
V>До этого минимум одна на входной механизм самописных очередей задач.
Ага. И после этого — ещё и постраничные блокировки по мере сканирования. Т.к. захватывать shared table lock на всё время транзакции — свинство даже на уровне serializable.

V>До этого на пул запросов, на ресурсы, требуемые для работы хотя бы парсера и валидации SQL, составления плана запроса согласно текущей схемы базы и т.д. и т.п.
Вот этого ничего не надо, т.к. ресурсы парсера и валидатора — не уникальные, и доступ к ним в синхронизации не нуждается. А блокировка на схему, от которой зависит валидность плана (и возможность построить план, если это нужно) уже упомянута.

V>Но в дефолтном алгоритме RO-RW блокировки аж три семафора, три недешёвых вызова АПИ ОС только на реализацию всего двух состояний СМО всего одного уровня из иерархии.
V>Разве не ого? ))
V>А если состояний "ячейки" СМО более одного (как ты там упоминал еще виды блокировок) — то и вовсе по-дефолту обычно делают на условной переменной, со всеми её suspicion wake up и чудовищной вероятности столкновения потоков на единственном мьютексе, обслуживающем эту условную переменную.
Воот. Постепенно вырисовывается понимание, почему у меня скепсис относительно больших выигрышей за счёт компиляции запроса. При "интерпретации" план строится из относительно крупных кубиков — ну типа "просканировать индекс вот с таким предикатом". Накладные расходы на состыковывание кубиков сопоставимы (на первый взгляд) с накладными расходами на "проверить, нужно ли захватить row lock для выполнения bookmark lookup, или уже захвачен более крупногранулярный lock".

S>> Показываю на пальцах: Допустим, у нас уровень параллельности = 8. Разделяемые блокировки на ресурсе реализуются как acquire(1), эксклюзивные — как acquire(8).
S>>Блокировки строки — опять же, acquire(1), страницы — acquire(8).

V>8 будет если на данном уровне иерархии ровно 8 фактических shared-владений.
V>А если одно?
V>А если ни одного?
Вот поэтому-то я и хотел, чтобы вы привели код. Какой смысл обсуждать свойства "моей" реализации "вашей" идеи?
Покажите мне код, который делает то, что вы написали.
V>Ты там цикл не видел разве в псевдокоде обновления счётчика?
А цикл-то тут при чём? Он же не от количества "владений" зависит, а только от наличия конфликтующих обновлений состояния самого семафора.

S>>Транзакция A продолжает работу, захватывает shared lock на записи номер 4, 5, 6, 7, 8, 9, 10 при помощи Page(42).acquire(1) — успешно.
V>Зачем?
V>Ты ведь уже shared-владешь страницей, т.е. можешь читать данные этой страницы "просто так".
Эмм, а откуда транзакция "знает", что уже shared-владеет страницей? В коде вашего семафора нет никакой информации о том, кто чем владеет. Если вы подразумеваете, что транзакция (или менеджер блокировок) ведёт таблицы владения, то стоимость операций над этими таблицами тоже нужно учитывать. То есть опять — даже в простейшем случае одноуровневой иерархии ресурсов у нас никак не хватает "единственной interlocked операции".

V>Это тогда надо заходить на страницу под другой дисциплиной блокировки, например, "я могу блокировать с разными дисциплинами произвольные твои строки конкуретно", и тогда страница не пустит shread-RO "клиентов" к себе.
V>И тогда acquire ты будешь запрашивать у конкретной строки, а не страницы, бо на страницу под нужной тебе прикладной дисциплиной ты уже вошёл.
Совершенно верно тогда надо помимо захвата "разделяемой блокировки" на уровне страницы дополнительно захватывать нужный вид блокировки на уровне строки. Я взял "разделямую" в кавычки потому, что на самом деле intent lock не во всех отношениях ведёт себя как просто shared lock, хотя в упрощённой модели их можно использовать взаимозаменяемо.
Как мы уже выяснили, нельзя просто захватить row lock — надо сначала захватить intent-блокировки на базу, таблицу, страницу.

V>Или, при реализации COW, если страница захвачена читателями и для тех уровни изоляции позволяют, твоя транзакция может поступить иначе — сделать копию страницы, обновить строки в этой копии, а потом обновит цепочку страниц (про COW тебе тоже говорилось сразу).
И я про COW сразу отвечал, что он убивает производительность даже при чтениях. Потому, что механика определения того, какая версия страницы является актуальной для данной транзакции, небесплатна.
V>А текущая страница для shared RO-заявок переходит в режим фантома и будет жить до тех пор, пока ею shared-владеют, потом тихо умрёт.
Вот вы же опять манипулируете какой-то магией. Вот это вот всё — "режим фантома" и прочее — это же всё не божьим промыслом происходит. Кто-то должен отслеживать состояния транзакций, которые видят фантомные страницы, и своевременно эти страницы помечать как свободные. Вы уверены, что понимаете, как это повлияет на производительность обработки запросов?

V>Здесь опять путаешь уровни иерархий.
V>Говорил же тебе — тупо пронумеруй, меньше вероятность ошибиться. ))
Нет, просто вы плохо объясняете свои мысли. Именно поэтому я хотел от вас кода. Потребовалось всего-то 20 постов туда-сюда, чтобы мы сошлись на недостаточности одной interlocked операции для сканирования таблицы.

V>Но тогда привет турникетам и база быстро встанет колом, при таком-то кол-ве уровней иерархии.
Нет, если мы чётко понимаем, чем отличаются блокировки строк от блокировок страниц, то никаких вставаний колом не происходит. Просто для модификации одной строки нужно захватить две блокировки — строки и страницы (в предположении, что блокировка таблицы уже захвачена).
V>Надеюсь, на следующей итерации у тебя будет получше с пониманием целевого — а зачем вообще требуется нетривиальная возня с режимами СМО.


V>Про уровни параллелизма когда речь, то ресурсом является вычислительный блок, (процессор, ядро, поток в ядре и т.д., смотря как железка устроена).
Ага. Именно поэтому в примере выше было взято число 8. А не, скажем, 2000 — что больше похоже на количество записей на странице.
V>Например, транзакция, выполняющая COW, делает обновления многошагово, т.е. через последовательность заявок.
V>Первая заявка иницировала транзакцию, произвела первое чтение.
V>Если были конкуретные чтения или даже чтения-записи, то в рамках транзакции могут создаваться копии данных, как упомянул выше. Одна операция чтения — один уровень параллелизма (допустим для простоты). В системах с отказами и последействиями, например, нужной страницы нет в памяти, — будет отказ и новая постановка в очередь с новым состоянием заявки (см эту категоризацию СМО, сама эта категоризация даёт много подсказок).
Я по-прежнему не вижу, чем эта категоризация СМО может помочь при проектировании СУБД.

V>Освободили "ресурс", т.е. процессор-ядро-поток, исполняем следующую заявку. Вполне может быть, что следующей будет заявка из той же самой транзакции, она ведь при инициализации могла накидать сразу пачку заявок, т.е. вероятность последовательного расположения заявок от одной транзакции будет высокой.
Ну вот с этой стороны я пока не очень понимаю, как это всё строить с точки зрения реализации. Что такое "заявка"? Task<T>?

V>В общем, тебе придётся найти подтверждение этой (уже не первой) инсинуации или прилюдно извиниться.
Какой?

V>Ага, т.е. я прав — ты теперь пытаешься замылить саму суть обсуждения, как обычно ища виноватых в своем непонимании на стороне. ))
Нет, я по-прежнему пытаюсь вернуть вас к сути. Обратите внимание — уже 20 постов я задаю одни и те же вопросы.
V>"На коленке" я жду от тебя куда как более примитивную часть этого кода — простое управление shared-exclusive доступом ко всего одному ресурсу, т.е. очень простой СМО из двух состояний.
Давайте лучше вы напишете эту часть кода. Которая хотя бы будет реентерабельной
Когда сделаете, можно будет перейти к вопросам со звёздочкой — например, что делать с deadlock? Но об этом поговорим потом

V>И жду понимание того, как с помощью аналогичных механизмов, раскиданных по разным уровням иерархий, реализовать комбинаторику возникающих сценариев при организации различных уровней изоляции.
вся "комбинаторика" при реализации различных уровней изоляции хорошо известна. Для неё не нужна никакая теория СМО. И даже гранулярность блокировок уровню изоляции ортогональна.
Уровни изоляции описываются тем, в какой момент захватываются и отпускаются shared lock, независимо от их гранулярности. Ну, кроме serializable, где важными становятся table и range блокировки.
А вы опять умничаете в области, с которой плохо знакомы.

V>И тогда ты будешь готов согласиться с самыми первыми моими заявлениями, насчёт простой нумерации уровней иерархий.


V>Ну конечно же да.
V>Потому что в какой-нить транзакции я могу по некоему условию менять даже схему таблиц, т.е. заранее неизвестно.
V>И тогда ACID на всех уровнях, кроме сериализованного не будет соблюдаться от момента начала такого участка транзакции, т.е. базе придётся войти в сериализованный режим.
)
Господи, чушь-то какая. Изменения схемы таблиц совершенно не требуют никакого глобального мутекса. Вы, наверное, не видели взрослых СУБД.
Изменения схемы прекрасно живут на блокировках схемы. Я могу стартовать транзакцию, выполнить в ней create table и пойти покурить, не делая commit — и никакие другие транзакции этого не заметят.
Я могу сделать alter table drop column — и он дождётся, пока последняя транзакция, использующая эту таблицу завершится, и дропнет колонку.
И если параллельно со мной никакие транзакции не работают конкретно с этой таблицей, то они прекрасно продолжат работать, как ни в чём не бывало.
Я не знаю, что вы называаете "сериализованным режимом", но если речь про захват глобального мьютекса — то нет, вы не угадали, для изменений схемы он не нужен, и настоящие СУБД работают не так.

S>>Почитайте любой учебник по СУБД.
V>Опять мимо, тут нужен учебник не для пользователя СУБД, а для разработчика СУБД (угу, не разработчика прикладной базы данных, а самой СУБД).
Из тех четырёх, которые я привёл, два — для разработчиков СУБД.

V>СМО — неотъемлимая часть такого учебника.
Давайте так: дайте ссылку на главу по СМО в любом учебнике по разработке СУБД на ваш вкус.

S>>Глобальная блокировка является достаточным, но вовсе не необходимым условием для serializability.
V>Опять та же ошибка — зависит от уровня иерархии оперируемой сущности.
Что именно зависит? Значение термина "глобальная блокировка"? Очень странно. Я полагал, что глобальность — она на то и глобальность, что одна на всех.

V>СУБД тут ни разу не уникальны, т.е. до смешного — сама попытка отослать к учебнику по некоей СУБД демонстрирует не просто непонимание предметной области, а отсутствие простой "записи" в эрудиции о наличии самой предметной области.
Не по "некоей СУБД", к учебнику по разработке СУБД.

V>В английском различают термины lock и block, в русском языке возникает путаница.
V>Поэтому, стоит использовать или английскую терминологию, или длинную русскую, навроде "блокировка для совместного доступа по чтению".
V>В русскоязычном IT "просто блокировка" означает blocking lock на английском.
Именно поэтому я ни разу не использовал термин "просто блокировка".
И в большинстве мест я использовал английскую терминологию. Очень странно с вашей стороны делать вид, что вы двадцать постов подряд не понимали, что мы обсуждаем СУБД.

V>Простой пример:
V>вот у тебя запрос с агрегацией только по чтению.

V>Какие могут быть уровни изоляции:
V>- никакой, т.е. код исполнения запроса читает и те данные, что уже есть и те, что были изменены; есть вероятность, что результатом агрегата станет такое значение, которое не могло быть ни в одном из "конечных" состояний базы, т.е. между транзакциями.

V>- ACID-изоляция; конкурентные транзакции не могут изменить твои данные; это может быть достигнуто исключительным доступом к таблице (блокировкой), либо же, транзакция, выполняющая агрегирующее чтение, будет работать с копиями данных, на момент начала чтения; вот тебе пример того, что блокировки и уровни изоляции — совсем не одно и то же;

V>- откаты/обработка конфликтов; например, самостоятельный перезапуск базой запроса, если уже просмотренные данные были изменены конкурирующими транзакциями;

V>Первый случай еще обычно разделяют на два-три, по степени допущения несогласованности, но пример с агрегатом был взят именно затем, чтобы отличаться от "простой выборки".
V>Именно в этом месте "учебники по СУБД" нехило улыбают, бо я привел пример одной из самых распространнёных ошибок подсчёта агрегата при неверно выбранном уровне изоляции.

Ок, хорошо, что вы привели конкретный пример. Его хотя бы можно обсуждать. Вот для банального агрегатного запроса типа select sum(salary) from employees; какой нужен уровень изоляции? Внезапно — repeatable read.
Если мы пошли по пути блокировок, внезапно оказывается, что совершенно необязательно захватывать исключительный доступ к таблице.
Достаточно удерживать разделяемую блокировку до конца транзакции.
Более того — даже делать её уровня таблицы совершенно необязательно. Можно захватывать shared page locks по мере сканирования данных — и всё ещё никаких проблем с сериализуемостью не будет.
Понятно, почему так происходит, или надо подробно разжевать?

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

V>Но недостаточно для моей задачи.
V>Если в рамках конкурирующей транзакции были изменены две строки данных, одну из них уже прочитали и подсчитали в агрегате, другую прочитали уже после фиксации конкурентной транзакции — агрегат выдаст фуфел на выходе.
Именно поэтому для данного запроса нужен repeatable read. А вот serializable — избыточен.

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

V>Какого именно утверждения?
Про то, что ACID достижим только при помощи одного глобального мьюьекса.

V>Системы резервирования работают, внезапно, через различные допущения с целью того самого ускорения обслуживания.
V>Например, работавшая (не знаю как сейчас) еще с 90-х система резервирования ЖД-билетов работала через пулы, раскиданные по звездообразной схеме.
V>При исчерпании пула у локального и вышестоящего узла, резервирование порой выполняется ооочень долго.
V>Потому что чудес не бывает.
V>Ты бы эта хотя бы свои собственные примеры проверял, прежде чем приводить их якобы в пример якобы своей правоты.
Печаль, печаль. Подумайте ещё раз: если бы ACID был недостижим без одного глобального mutex, то резервирование бы было медленным всегда, а не при "исчерпании пула".

V>А с современными скоростями интернета и быстродействием серверов и этого уже не требуется, ведь "один мьютекс" нужен не на всю базу ЖД-трафика, а на конкретный рейс, т.е., подозреваю, с пулами сегодня никто не возится, достаточно обеспечить fault tolerance, задача поиска свободных мест из десятков-сотен значений сегодня занимает микросекунды.
Хм, опять началась какая-то каша в голове. Что такое "глобальный мьютекс на конкретный рейс"? И чем он отличается от "локального мьютекса"?
Вы совершенно напрасно изобретаете какую-то самодеятельную терминологию.

V>И да, при попытке фактического резервирования repetable read уже не катит, упс?
С чего вы это взяли? Смотря что входит в "фактическое резервирование" — может хватить даже read committed. Попробуйте продемонстрировать контрпример

V>Зато прекрасно катит автоматический откат и повторное резервирование, скажем, на рейсы с пересадкой, когда при последовательном резервировании одно из них вышло неудачным.
V>(третий упомянутый алгоритм обеспечения согласованности)
Да, расскажите мне про optimistic locking. Но лучше — в другой раз. Там всё сложнее, чем кажется на первый взгляд, а вы ещё с pessimistic locking не разобрались.

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

V>>Синклер:
V>>- Неадекватное решение — реализация набора видов блокировок в СУБД через самописанный семафор, поддерживающий отрицательные значения счётчиков.
V>>Я:
V>>- твоё утверждение ложно, бо в СУБД широко используют именно самописные семафоры.
S>Ну разве можно так бессовестно передёргивать? Все ходы записаны.

Да ля вертеться-то, это именно таков обмен "аргументами", твои цитаты дословные.
Вот два твоих последовательных поста:
http://www.rsdn.org/forum/flame.comp/8109346.1
http://www.rsdn.org/forum/flame.comp/8111608.1

Забористая каша, плаваешь в терминах, плохо представляешь себе происходящее в СУБД.

Но тех цитатах забавны даже не сами они, а их "последовательность", бгг...
За подобный уровень как владения материалом, так и навыков обмена аргументацией должно быть невыносимо стыдно, ИМХО.


S>Я вас просил привести решение задачи

Какой именно задачи? ))
Прежде чем проcить решение задачи, задачу надо сформулировать.
С этим ты не справился пока.

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

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


S> — вы начали с описания некоего решения на основе семафора;

"Некоего решения"

Начал-то я немного с другого, с того, что "прикладные виды блокировок" в отсутствии понимания, что они из себя представляют унутре, лишь засоряют твой моск.
Отсюда и понеслась. ))

В кач-ве демонстрации выбрал RO-RW примитив синхронизации, переключающий режим своей работы.
Этот примитив синхронизации можно рассматривать в виде СМО с двумя состояниями и с очередью с ожиданиями (см. классификацию СМО).

Была рассмотрена специфика проектирования СМО под конкретный вид нагрузок, в данном случае, когда трафик читателей намного больше трафика писателей, тогда в простейшей реализации возможно голодание писателей.

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


S>затем оговорились, что это решение — плохое, поэтому нужно добавить ещё один семафор, впрочем это решение тоже плохое, поэтому нужно использовать пользовательские очереди задач.

Верно, тебе демонстровали влияние характера поступающих заявок на ход решения, т.е. на разрабатываемые алгоритмы реализации такой СМО.

Фактор голодания писателей важный и был приведён не просто так, бо в СУБД ситуация аналогичная и об этом тоже упоминалось — операций чтения всегда намного больше операций записи.
А в условиях проверки целостности, даже если в данный момент поступают лишь построчные операции записи в базу, то на запись одной строки приходится производить огромное кол-во чтений.

Всё это озвучивалось, просто ты порой потрясающе невнимателен.


S>При этом изо всего этого ряда решений код вы привели только для первого, и то неполный, а в стиле "вот вам int main(){}, остальное впишите между фигурными скобками".

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

Если уж приводить аналогию, то тебе дали ф-ию, допустим, ssize_t read(fd, void *, size_t) и сказали — теперь ты сможешь прочитать файл построчно, при надобности.

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

Мне от собеседника требуется демонстрация хоть какого-то понимания и не самого низкого уровня сообразительности.
Если человек не сможет через read и небольшой буфер сам, без подсказок, написать алгоритм построчного чтения файла, ему лучше сходу слиться.

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

НС>>Статистику сам собирал?
I>По всякому, что то сам, что то люди рассказывают.

Ну то есть ты решил придумать факт.

I>Собственно, кроме тебя и Вдимаса никто не рассказывает про чудеса кофе из автомата.

О, опять чучелко. Я не рассказывал про чудеса кофе из автоматов.

I>И в сетевых кофейнях автоматы вымерли.

Опять придумываешь факты?

I>Вобщем, это тебе бы статистику пособирать

Полетели чайники.

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

Конечно. И?

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>Статистику сам собирал?
I>>По всякому, что то сам, что то люди рассказывают.

НС>Ну то есть ты решил придумать факт.

Так себе тактика — вместо того, что бы аргументировать, спросить, уточнить, тупо обвиняешь во лжи.
Выглядит так, будто для тебя любой чужой опыт ничего не значит.
Ты сам можешь видеть, что пишет тот же Синклер. Но для тебя и это не аргумент. Это же Синклер, а не ты.

I>>Собственно, кроме тебя и Вдимаса никто не рассказывает про чудеса кофе из автомата.
НС>О, опять чучелко. Я не рассказывал про чудеса кофе из автоматов.

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

I>>И в сетевых кофейнях автоматы вымерли.
НС>Опять придумываешь факты?

I>>Вобщем, это тебе бы статистику пособирать
НС>Полетели чайники.

Забавно, снова твой любимый аргумент. Если ты спрашиваешь про статистику у меня — это нормально. А если я у тебя — сразу "чайник".

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

НС>Конечно. И?

Ответ на твой "И?" в той части, что ты скипнул:

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

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

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

НС>>Ну то есть ты решил придумать факт.
I>Так себе тактика — вместо того, что бы аргументировать, спросить, уточнить, тупо обвиняешь во лжи.

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

У тебя есть опыт по анализу времени обслуживания кофе-машин в РФ? Рили?

I>Ты сам можешь видеть, что пишет тот же Синклер

Синклер не делает обобщающих выводов, в отличие от.

I>>>Собственно, кроме тебя и Вдимаса никто не рассказывает про чудеса кофе из автомата.
НС>>О, опять чучелко. Я не рассказывал про чудеса кофе из автоматов.
I>"Чудеса" это в данном случае должный уход за автоматами.

И что тут чудесного? В должностной инструкции сетевых кофеен прописан вполне конкретный регламент, за его несоблюдение штрафуют. Никакого чуда здесь нет.
Ну а во всяких макдачках или тех же заправках ГПН, как я уже писал, автоматы сами себя чистят периодически, без участия человека.

I>>>Вобщем, это тебе бы статистику пособирать
НС>>Полетели чайники.
I>Забавно, снова твой любимый аргумент.

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

I> Если ты спрашиваешь про статистику у меня — это нормально.

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

I>>>На мой взгляд, тут причины исключительно денежные.
НС>>Конечно. И?
I>Ответ на твой "И?" в той части, что ты скипнул:

Нет там ответа. Зачем ты это утверждение сделал? С этим кто то спорил?

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

V>Забористая каша, плаваешь в терминах, плохо представляешь себе происходящее в СУБД.
Вот вы же себя сейчас описываете.


S>>Я вас просил привести решение задачи

V>Какой именно задачи? ))
V>Прежде чем проcить решение задачи, задачу надо сформулировать.
Ок, вернёмся на сто шагов назад.

S>Даже в отсутствие конфликтов блокировки отжирают время.
В отсутствии конфликтов — одна интерлокед-операция на таблицу для скана таблицы.
Считай, бесплатно.

Видите, с чего всё начинается? Я вам пытаюсь объяснить простую вещь: себестоимость поддержки изоляции транзакций на фоне затрат на интерпретацию планов запросов. Вы — не вьезжаете, и начинаете писать чушь.
В следующем посте я уточняю область моей обеспокоенности:

Вопрос — в том, как обеспечить быстродействие в реальных задачах, особенно когда планировщик заранее не знает, сколько строк попадёт под предикат.

Вот она, эта задача. Все самописанные "быстрые" приложения поверх локальных СУБД работают в недостижимых для сервера приложений тепличных условиях — например, однопользовательский режим работы (и однопоточный движок исполнения транзакций), и рудиментарыне возможности по восстановлению после сбоев.
Механизмы обеспечения A, I, и D в ACID хорошо известны и изложены в той самой литературе, которую вы избегаете читать (но регулярно пытаетесь отправить её читать меня).
Вопрос — в себестоимости этих механизмов.

V>Начал-то я немного с другого, с того, что "прикладные виды блокировок" в отсутствии понимания, что они из себя представляют унутре, лишь засоряют твой моск.
V>Отсюда и понеслась. ))
А то. Невооружённым взглядом видно, что отсутствие знаний о "прикладных видах блокировок" мешает вам осмысленно обсуждать устройство СУБД, хоть реальных существующих, хоть воображемых будущих.
Так как вы не очень представляете требования к менеджеру блокировок в СУБД, вы начинаете изобретать нерабочие велосипеды.

V>Верно, тебе демонстровали влияние характера поступающих заявок на ход решения, т.е. на разрабатываемые алгоритмы реализации такой СМО.
Ну и зачем вся эта феерия? Мы ни на йоту не приблизились к пониманию того, что реально происходит в СУБД при захвате блокировки.

V>Всё это озвучивалось, просто ты порой потрясающе невнимателен.
Ну так а толку всё это озвучивать, когда эти факты никакого влияния на ход вашего решения не оказывают? Ваш семафор не умеет делать банальную конверсию read lock в write lock. Голодание писателей — это десятая по важности проблема после базовой функциональности, без которой о реализации изоляции транзакций в СУБД и заикаться нечего.
Для интересу, можете ознакомиться с тем, что происходит в настоящих СУБД на примере вот этой статьи.
Там упрощённый псевдокод, но он даёт ровно то, что нужно — понимание, какие операции выполняются, где синхронизация, где interlocked. Можете сравнить со своим кодом, который одновременно слишком низкоуровневый, и слишком "общий".
Кроме псевдокода можно посмотреть на то, какие факторы влияют на быстродействие механизма блокировок. В частности, как раз те самые операции над списками блокировок, о которых у вас вообще не упомянуто — и ровно потому, что вы понятия не имеете, что и зачем вынуждены делать реальные СУБД. На фоне вот этих приседаний ваша экономия легковесным семафором — спички.


V>Тебе привели ключевое — как писать свои примитивы синхроизации для кода, работающего поверх выталкивающей многозадачности.
)

V>Твои возмущения "да я не вижу здесь кода построчного чтения файла" воспринимаются до поры до времени с нисходительностью...
V>Но в какой-то момент обязательно пошлют, не переживай. ))
Да я и не переживаю. Мне просто интересно, чем это кончится. У вас же есть два режима общения. Один — это кривляния. Для меня они заходят в качестве вечернего развлечения, вроде comedy club.
А второй режим — когда вы внезапно перестаёте выделываться и пишете по делу.
V>Если человек не сможет через read и небольшой буфер сам, без подсказок, написать алгоритм построчного чтения файла, ему лучше сходу слиться.
Видите ли, чтобы претендовать на позицию учителя, нужно быть готовым самому "сесть за руль". Но вот за вами такой готовности незаметно — ни в этом топике, ни в каких других. У вас всегда наготове критика, переваливание ответственности на других, и смелые заявления "я бы сделал лучше". Вот только наблюдаемый результат — это либо ссылки на ноу-хау, либо "я вам дал подсказку, дальше сами". Фу таким быть.
То, что вы делаете — это совершенно прозрачная попытка скрыть свои затруднения и непонимание за менторским тоном.
И определяется это очень легко — можно просто брать любой ваш ответ и сравнивать с тем постом, на который он отвечает. Вот скипнутые вами вопросы — и есть те места, в которых вы плаваете, а признаться стрёмно.

Мне вот совершенно не стыдно признаться в том, что я не очень хорошо разбираюсь в многопоточном программировании, и, скажем, не могу (в отличие от многих коллег на форуме) сходу ткнуть пальцем в код синхронизации со словами "у вас тут гонка". Зато я хорошо разбираюсь в том, как работают различные СУБД, от игрушечных до промышленных. И разбираюсь я в этом не для того, чтобы унижать людей на форумах — в отличие от вас, мне не стрёмно объяснить кому угодно непонятные места. Я поэтому и преподавать пошёл.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>Ну то есть ты решил придумать факт.
I>>Так себе тактика — вместо того, что бы аргументировать, спросить, уточнить, тупо обвиняешь во лжи.

НС>Я не обвинял тебя во лжи, я обвинил тебя в том что ты просто придумываешь факты.

ты сам то понял что сказал? Придумывание фактов и есть ложь.
На каком основании ты меня обвиняешь?

I>>Выглядит так, будто для тебя любой чужой опыт ничего не значит.

НС>У тебя есть опыт по анализу времени обслуживания кофе-машин в РФ? Рили?

Конкретно про Россию это мои поездки, знакомства и лекции ваших же специалистов.

I>>Ты сам можешь видеть, что пишет тот же Синклер
НС>Синклер не делает обобщающих выводов, в отличие от.

Похоже ты ждешь монографию по исследованию рынка.

I>>"Чудеса" это в данном случае должный уход за автоматами.

НС>И что тут чудесного? В должностной инструкции сетевых кофеен

В какой сетевой КОФЕЙНЕ ты видишь те самые автоматы? Надеюсь под автоматами ты подразумаваешь те, что и весь цикл делают, а не традиционные рожковые машины?

> прописан вполне конкретный регламент, за его несоблюдение штрафуют. Никакого чуда здесь нет.

К обслуживанию это не сводится. Я привел примеры.

НС>Ну а во всяких макдачках или тех же заправках ГПН,

Макдак это не кофейня, и заправка это не кофейня. Даже мцкафе это не совсем кофейня и там рожковые стоят. Я других не видел. Ты про что пишешь то?

> как я уже писал, автоматы сами себя чистят периодически, без участия человека.

Это все нормальные автоматы так делают, но этого мало.

Кроме того, сам по себе регламент погоды не сделает. Например, зерно сыплют какое есть, вон Лавацца-Якобс-Или падяшэуле, а не бугут за свежеобжареным моносортом в пятеро дороже. И помол на глазок, абы жижа текла. А чо — все по регламенту.

I>>>>Вобщем, это тебе бы статистику пособирать
НС>>>Полетели чайники.
I>>Забавно, снова твой любимый аргумент.

НС>Это не аргумент, это твой любимый прием.

Указывать на чайники — это твое. Не надо мне этого приписывать.
Может я чего то не понял — процитируй и объясни про "прием".

I>> Если ты спрашиваешь про статистику у меня — это нормально.

НС>Ты, я вижу, по прежнему не понимаешь что такое чайник Рассела.

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

НС>Да, нормально. Потому что это ты сделал утверждение, и это на тебе обязанность его обосновывать.

А тебе не надо? Ты уже и к обвинениям перешел, и оснований я шота не вижу.

I>>Ответ на твой "И?" в той части, что ты скипнул:

НС>Нет там ответа.

Вероятно, я не сильно понимаю твои короткие ответы, намеки и тд. Не сильно то похоже, что ты стараешься изъясняться понятно для собеседника.

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

V>>Прежде чем проcить решение задачи, задачу надо сформулировать.
S>Ок, вернёмся на сто шагов назад.
S>

S>>Даже в отсутствие конфликтов блокировки отжирают время.
S>В отсутствии конфликтов — одна интерлокед-операция на таблицу для скана таблицы.
S>Считай, бесплатно.

S>Видите, с чего всё начинается?

Ну так и с чего? Смелее!
Что ты как брат нибэнимэда? ))

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

Итак, ты прочитал это как "операций интерлокед-характера требуется одна штука", или как "операция вообще одна, которая интерлокед и есть".

Кароч, Синклер, хватит, сорри за мой французский, сцать!
Говори уже прямой речью.


S>Я вам пытаюсь объяснить простую вещь: себестоимость поддержки изоляции транзакций на фоне затрат на интерпретацию планов запросов.

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

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

Ну и, опять поторопимшись здесь тоже косячишь — для составления собсно плана тоже блокировки нужны, на уровень схемы хотя бы.
И на статистику индексов (с некоторой вероятсностью) и т.д..


S>Вы — не вьезжаете, и начинаете писать чушь.

Так не въезжаю во что именно?

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

Но как быть с твоим гаденьким способом сливаться на бабский (в плохом смысле этого слова) манер оставления за собой уже абы какого последнего слова: "и всё-равно вы ничего не понимаете"? На дуэль бабомужика вызывать или как? ))


S>В следующем посте я уточняю область моей обеспокоенности:
S>

S>Вопрос — в том, как обеспечить быстродействие в реальных задачах, особенно когда планировщик заранее не знает, сколько строк попадёт под предикат.

Бгг...
Ситуация:
— Как работает двигатель?
— ОК, начнём с основных составляющих, вот поршни, вот цилиндры, ...
— Стойте, стойте! Как РАБОТАЕТ двигатель?
— (Ммм, наверно отличник какой-то) ОК — вот простейший адиабатический процесс, предлагаю разобрать сначала его, потому что реальные процессы в двигателе описываются более сложными моделями, чем адиаба...
— Я вас спросил КАК. РАБОТАЕТ. ДВИГАТЕЛЬ??? А не про поршни, и эти ваши дурацкие про... про... проссесцы, или как их там, даже запоминать эту чушь не хочу!!!


S>Вот она, эта задача.

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

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


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

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

Именно поэтому меня улыбает, когда многие упоминавшиеся тобой вещи ты пытался приписать сугубо СУБД.
Это общая практика проектирования подобных систем, где большое кол-во структурированных данных активно обновляется достаточно большим хаотичным трафиком.


S>Механизмы обеспечения A, I, и D в ACID хорошо известны и изложены в той самой литературе, которую вы избегаете читать (но регулярно пытаетесь отправить её читать меня).

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

Всё что написано в той литературе, куда ты пытаешься отслать, грамотному специалисту можно изложить на одной-двух страницах, даже если он раньше никогда не слышал.
Если слышал — просто перечислить в одной-двух строках.

Это как взять Капитал Маркса — суть произведения можно изложить ровно в 3-х абзацах:
— прошлое и настоящее (на тот момент) капитализма;
— выведенная закономерность превращения капитализма в империализм;
— найденная формула "угнетения народных масс" — т.н. добавочная стоимость.

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


S>Вопрос — в себестоимости этих механизмов.

Вот, про себестоимость — это ко мне.
Хотя ты несколько раз повторил, что это тебе не интересно.

Но вопрос в том числе в ней, родной, ес-но.
Бо когда у нас "себестоимость" изменяется в 50 и более раз только за счёт изменения механизмов и самих принципов "синхронизации", то я в этих устрицах знаю толк.


V>>Начал-то я немного с другого, с того, что "прикладные виды блокировок" в отсутствии понимания, что они из себя представляют унутре, лишь засоряют твой моск.
V>>Отсюда и понеслась. ))
S>А то. Невооружённым взглядом видно, что отсутствие знаний о "прикладных видах блокировок" мешает вам осмысленно обсуждать устройство СУБД

Ой дичь.
Такие вещи идут как постановка задачи, а не "добываемые с трудом знания".

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

Просто ты не видишь, что ле, изначальной цели этого обсуждения.
А она проста: угостить одной рыбёшкой и научить ловить рыбу — разные вещи.


S>Так как вы не очень представляете требования к менеджеру блокировок в СУБД, вы начинаете изобретать нерабочие велосипеды.

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


V>>Верно, тебе демонстровали влияние характера поступающих заявок на ход решения, т.е. на разрабатываемые алгоритмы реализации такой СМО.
S>Ну и зачем вся эта феерия?

Иначе не понять, т.е. даже не суметь сформулировать задачу.
Так и будешь барахтаться на уровне "продвинутого юзверя".

Есть такая присказка — молодец посредь овец, и далее по тексту.

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

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

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

И да, мне неоднократно в своей жизни требовалось применять наработки из ТАУ к алгоритмам, управляющими режимами работы СМО.
Сложнее второго порядка цепь управления не делал, но даже второй порядок позволяет скачкообразно поднимать "умность" железки на новый уровень, бо та начинает уметь отделять средний текущий трафик от мгновенных его флуктуаций, и эти данные исопльзуются в алгоритмах управления состоянием СМО. И да, как раз в алгоритмах распределённых транзакций и восстановления после сбоев.

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

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

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


S>Мы ни на йоту не приблизились к пониманию того, что реально происходит в СУБД при захвате блокировки.

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

Я это вижу как банальную трусость.


S>Ну так а толку всё это озвучивать, когда эти факты никакого влияния на ход вашего решения не оказывают? Ваш семафор не умеет делать банальную конверсию read lock в write lock.

Код целиком не привели? (опять ржу че-та)

На это тебе уже ответили — ф-ия read из CRT тоже не умеет читать файл построчно, но с помощью этого read построчно прочитать файл элементарно.
С помощью уже показанного тебе кода нарисовать RO-RW замок — как два пальца об асфальт.
Т.е. простейшую СМО с двумя состояниями.

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


S>Голодание писателей — это десятая по важности проблема после базовой функциональности

Мде? ))

Без учёта эффекта голодания писателей, при увеличении трафика читателей писатели вообще не смогут достучаться до ресурса ни-ко-гда.
Т.е., чем ближе к 0-лю вероятность нулевой длины очереди читателей (в любой конкретный момент времени), тем ближе к бесконечности очередь писателей.

Т.е., не обязательно писать конкретный код, расписывая до компилябельности и обыгрывания всех граничных случаев, по дороге борясь с конкретным ЯП.
Иногда достаточно на принципиальном уровне рассмотреть происходящее в том или ином алгоритме.

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

С тойбо делились тем наблюдением, что в любой реализации требуемого "замка" могут быть некие заведомо "встроенные" в данную реализацию проблемы.
Тебе показали (А) — что проблемы в хаотичном трафике бывают и (Б) что обнаружение проблем еще на стадии анализа/моделирования и их решение является неотъемлимой частью разработки.


S>без которой о реализации изоляции транзакций в СУБД и заикаться нечего.

Для особо одарённых еще раз — уровни изоляции не равны блокировкам.

Тебе уже дважды объясняли, как изоляция страницы для читателей может быть выполнена только через shared-блокировку её по чтению, через механизм COW.
Через это работают в т.ч. твои repetable read.

До смешного, тебе рассказывают об этом механизме уже несколько постов, а ты потом преподносишь repetable read как откровение.
Ситуация забавна — у тебя отсутствует сопоставление между названиями "блокировок" и реально происходящего в базе.


S>Для интересу, можете ознакомиться с тем, что происходит в настоящих СУБД на примере вот этой статьи.

Ознакомился, рассмотрена реализация специфичной хеш-таблицы для многопоточности, и?
Не так давно я тебе тоже описывал способы построения специфичных для многопоточности хеш-таблиц, И? (С большой "И")

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

Тебе говорили прямой речью несколько раз — от тебя требуется проявить (А) интерес и (Б) способность к восприятию информации.
Иначе нахрена твоему собеседнику против ветра мочиться-то? ))


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

Именно так.
"Фундаментальные" вещи, они именно такие.
Это те, через комбинаторику которых остальное "выводится".


S>Кроме псевдокода можно посмотреть на то, какие факторы влияют на быстродействие механизма блокировок. В частности, как раз те самые операции над списками блокировок

Только не списками, а некоей иерархией, в статье "LOCKING WITH LESS LATCHING".
Т.е. модель-то простая — введен однонаправленный граф отношений блокировок.
Я предлагал просто пронумеровать, помнишь?

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


S>о которых у вас вообще не упомянуто

Да упомянуто сто раз и по-разному.

Например, когда я поправлял тебя, что если ты захватил страницу по shared-чтению, то тебе не требуется блокировать по чтению отдельные строки этой страницы.
И я был сильно удивлён, поправляя тебя в этих местах.
Ты ж ни в зуб ногой, как оно унутре может быть устроено...


S>и ровно потому, что вы понятия не имеете, что и зачем вынуждены делать реальные СУБД.

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

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


S>На фоне вот этих приседаний ваша экономия легковесным семафором — спички.

Ага, раз в 50 разница в эффективности всей системы, а так-то мелочи.
Ты статью-то по своей ссылке читал?
В код вникал?
Похоже ты не обратил внимание, что в исходном коде MySQL "объект-замок" (create_lock) — это не "семафор" и никакой другой встроенный примитив синхронизации.

И что проблема в том коде конкретно вот здесь:
mutex_enter(lock_table->mutex)

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

И беседа забавная именно по этой причине у нас выходит: "ты куда, в баню? — да нет, в баню".

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


V>>Твои возмущения "да я не вижу здесь кода построчного чтения файла" воспринимаются до поры до времени с нисходительностью...
V>>Но в какой-то момент обязательно пошлют, не переживай. ))
S>Да я и не переживаю. Мне просто интересно, чем это кончится.

От тебя зависело.
Проявил бы желание разобраться — разобрали бы.
Встал в позу — равно или поздно был бы всё-равно послан.
Я просто даю обычно некоторое время собеседнику пройти от стадии отрицания до стадии понимания-угомонения.

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


S>У вас же есть два режима общения. Один — это кривляния.

Ну да, это же такое было моё кривляние — объяснение проблематики RO-RW и объяснение — зачем вообще вся эта проблематика озвучивается, да еще в кач-ве демонстрации характера задач, которые приходится решать.

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

Теперь ты просто удобный манекен для демонстрации того, каким быть нельзя.


S>А второй режим — когда вы внезапно перестаёте выделываться и пишете по делу.

Та я ваще пофигист.
Сказано же — от тебя зависит.
Показываешь себя гадливо-обидчивым на какую-то феерически-ничтожную с моей колокольни весч — не обессудь.


V>>Если человек не сможет через read и небольшой буфер сам, без подсказок, написать алгоритм построчного чтения файла, ему лучше сходу слиться.
S>Видите ли, чтобы претендовать на позицию учителя, нужно быть готовым самому "сесть за руль".

Во-во, "претендовать". ))
Хулиганы зрения хлеба лишают?
Да понятно это стало уже с 3-го твоего поста здесь...

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


S>Но вот за вами такой готовности незаметно — ни в этом топике, ни в каких других. У вас всегда наготове критика, переваливание ответственности на других, и смелые заявления "я бы сделал лучше".

Нормальные заявления в подходящих для этого местах.
Я же не просто говорил "там можно было сделать лучше", я озвучил — как именно.

Да и ты своим "умозрительным кодом" не возражал, а подтверждал, помнится, что аж в какой-то момент натурально надоел.
Еще и тем, что строил ответы якобы в виде возражений, лишь подтверждая "умозрительностью" мою основную мысль о де-факто состоянии мн-ва дотнетных дров к СУБД.


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

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

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

Потому что похожие задачи сплошь и рядом возникают не только в СУБД, ес-но.

У СУБД своя специфика, понятно, свои наработки, показавшие себя лучше всего за все эти 30 лет их успеха, что-то показавшее себя неважно уже умерло и т.д.
Т.е., в других задачах, вполне вероятно (и оно так и есть) может быть другой список и блокировок, и отношений м/у ними — это часто еще зависит от характера задач и данных.

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

Но общий принцип решения "задач о блокировках" — он, считай один.
Других наработок как теоретических, так и в плане иммитационного моделирования, чем СМО на сегодня банально нет.

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

Это перекликается с твоим столь же ожесточённым отрицанием DDD — в разработке сложных современных ПО-систем выжил только этот подход, другие умерли за несостоятельностью.
А этот выжил по простой прчине — является проекцией системного подхода на случай, когда речь сугубо о ПО (в общем случае на наших специальностях натаскивают на разработку аппаратно-программных комплексов, т.е. разработка только ПО — это несколько ограничение "потолка" роста, и это местами немного угнетает... хотя, нехило компенсируется зарплатой... но такова специфика экс-СССР айти).

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


S>То, что вы делаете — это совершенно прозрачная попытка скрыть свои затруднения и непонимание за менторским тоном.

У меня пока одно затруднение — ученик отказывается учиться.
И не в том ученик уже возрасте, когда есть возможность надавить/заставить, через родителей, просто поругать и т.д. ))


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

Ничего не было скипнуто, ля врать-то. ))
Я отвечаю на всё подряд в каждом посте, пока не надоедает.

Обычно набирается твоих 3-5 залётов — и я отправляю тебя на новый круг, бо этот считается непройденным.

Но и это не всё...
Вот это твоё постоянное замыливание, вся эта мышиная возня какая-то мелочная-дурацкая...

Ну какой смысл читать человека дальше, если он в одном абзаце делает некое предположение, порой даже скромным тоном, а в следующих уже рассуждает восю так, будто эти предположения верны? ))
Мляха, 20+ лет стажа на форумах, а ты мне эти "приёмчики" тулишь...
Как от кислого лимона на эту хрень у меня реакция.

И всё больше уверен, что это тупо отлынивание от изучения предмета, банально лень ума.
Хочешь болтать тупо ни о чём? ))

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


S>Мне вот совершенно не стыдно признаться в том, что я не очень хорошо разбираюсь в многопоточном программировании, и, скажем, не могу (в отличие от многих коллег на форуме) сходу ткнуть пальцем в код синхронизации со словами "у вас тут гонка".

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


S>Зато я хорошо разбираюсь в том, как работают различные СУБД, от игрушечных до промышленных.

И как в этом можно разбираться, не разбираясь в многопоточности?

Путаешь с "ознакомиться с руководством пользователя".

Это как с языком программирования — если сможешь написать для некоего ЯП компилятор-интерпретатор — ты понял этот язык.
Не сможешь — еще не понял.

С СУБД аналогично.
Сможешь их писать, от парсера КС-грамматики SQL, через преобразование/факторизацию уравнений РА (с целью приведения к шагам твоего "плана запроса") и до исполнения этого плана в конкурентной среде — тогда ты понимаешь, что в СУБД происходит. Нет — нет. Тогда ты просто "администратор БД".


S>И разбираюсь я в этом не для того, чтобы унижать людей на форумах — в отличие от вас, мне не стрёмно объяснить кому угодно непонятные места. Я поэтому и преподавать пошёл.

Ты преподаешь ведущим специалистам с 30-тилетним стажем?
Сорри, но не верю.

А может ты лекции читаешь студентам, т.е. минимум доцент?
А на какую темы был диссер, почему не похвастался еще?

Или ты там лаборант/практик?
А мне тут втирать опять изволишь?

Тут же почти все твои собеседники имеют ВО, прекрасно в курсе, что лаборантами/практиками работают даже зеленые аспиранты, которые вот только сами ВУЗ закончили.
Ну и я в ВУЗ-е остался сначала, но в первый же год был вынужден уйти из-за ничтожной ЗП, И? (большое "И")
А корешь остался, правда, ненадолго.

Это таков был "последний аргумент?"

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

В общем, если ты этим прямо заявляешь, что ученик в тебе умер — так можно уже хоронить. ))

(фуф, пипец)

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

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

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

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

V>Так не въезжаю во что именно?
Не въезжаете в механику работы управления блокировками в СУБД. Причём — снизу доверху. То есть не понимаете, какие блокировки в какие моменты захватываются, в какие — отпускаются.
Не знаете, какие действия выполняются при выполнении захвата блокировки. Не понимаете, чем отличаются одни виды блокировок от других.

V>Именно затем, чтобы их можно было предметно оспорить, я ведь могу тоже ошибиться, не так понять и т.д.
То-то вы пропускаете в ответах те места, где я предметно оспариваю ваши заблуждения (ну, например, про недостаточность уровня repeatable read для выполнения агрегатного запроса).

V>Создай под эту задачу другой топик и обсуждай.

V>И наберись мужества не пытаться заниматься подменой тезисов в том топике, а то тебя колбасит нипадецки.
Ну, и какой же тезис был до "подмены" по вашему?
V>А мы обсуждали устройство блокировок (лучше "замков"-lock, как в исходной семантике, бо к одному замку может быть много экземпляров ключей, например, а к другому один, и тогда владелец ключа "заблокирует" остальных).
Лучше не изобретать новых терминов, а пользоваться существующими. И в обсуждении блокировок мы так и не продвинулись — с вашей стороны не поступило ничего, кроме недосемафора и сферо-вакуумных рассуждений уровня "там очереди и задачи". А ведь с самого начала интересовало устройство кода acquire_shared_lock(transactionID, resourceID). Всего кода, а не только маленького фрагмента одного из возможных путей исполнения.

V>Ни в коем случае не к этой литературе, бог с тобой.
V>Я тебя пытаюсь отправить к литературе для разработчика.
V>А ты капризничаешь "нихачу".
Неа. Я уже просил вас привести ссылку на учебник по разработке СУБД. Вы, как обычно, тихо проигнорировали вопрос. Думаете, я не знаю причину? Трудно прислать ссылку на учебник, которого никогда в глаза не видел.

V>Всё что написано в той литературе, куда ты пытаешься отслать, грамотному специалисту можно изложить на одной-двух страницах, даже если он раньше никогда не слышал.
V>Если слышал — просто перечислить в одной-двух строках.
Можно. Но вы перечислению в двух строках не верите, а расписывать вам на двух страницах... Ну, разве что если вежливо попросите.

V>Вот, про себестоимость — это ко мне.
V>Хотя ты несколько раз повторил, что это тебе не интересно.
Почему? Мне интересно. Но вы избегаете разговоров о ней, отвлекаясь на посторонний булшит.

V>Такие вещи идут как постановка задачи, а не "добываемые с трудом знания".
Вот именно. А вы пытаетесь проскочить этап постановки задачи, переходя сразу к семафорам. "Вот! Вот икс!".

V>Тем более, когда виды блокировок можно упорядочить.
А что делать, когда нельзя? Я же неспроста вас уже трижды просил привести вот это вот "упорядочивание". За это время уже десять раз можно было погуглить таблицы совместимости блокировок и ответить "извините, был неправ, погорячился".
V>А она проста: угостить одной рыбёшкой и научить ловить рыбу — разные вещи.


S>>Так как вы не очень представляете требования к менеджеру блокировок в СУБД, вы начинаете изобретать нерабочие велосипеды.
V>Не докажешь "нерабочесть" — пойдёшь за пустомелю.
Да как два пальца.
1. Транзакция T1 захватывает разделяемую блокировку (shared lock) на страницу P1.
2. Транзакция T2 хочет захватить эксклюзивную блокировку на строку R1 страницы P1.
2.1. Для этого ей, очевидно, нужно сначала захватить какую-то блокировку на страницу P1. По-вашему, это будет shared lock (ведь "Заявки, блокирующие строки, эквиваленты читателям, а блокирующие всю страницу — писателям", (c) vdimas), тем более, что никаких других блокировок ваш воображаемый недописанный семафор не умеет.
2.2. Опять же очевидно, что этот захват второго shared lock на P1 транзакцией T2 будет успешным.
2.3. Транзакция T2 продолжает операцию и захватывает exclusive lock на P1:R1. Захват опять успешен, т.к. никаких других блокировок на P1:R1 в системе нет.
3. Транзакция T2 вносит изменения в P1.R1 и коммитится.
4. Транзакция T1 с удивлением обнаруживает, что несмотря на удерживаемый ей shared lock на страницу P1, в страницу были внесены изменения во время удержания этой блокировки. Фиаско.

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

Сможете сходу сказать, не подглядывая в мануал, intent exclusive page блокировка будет совместима с shared page блокировкой? А с другой intent exclusive блокировкой на ту же страницу?
Какие "номера" вы им присвоите?

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

V>Взять что угодно, например как ты описал как-то из своего студенчеств алгоритм "быстрого" переключения холодной и горячей воды для поддержки температуры (в баке, вроде бы), и тебе сходу несколько коллег указали на то, что это не поможет, если труба достаточно длинная ("длиннее" периода переключения), что это уже необходимо задействовать ТАУ, т.к. там требуется дифференциально-интегральное управление.
Это вы фантазируете. Точнее, перевираете с точностью до наоборот.

V>Т.е., ты там спрашивал — а как решать, всю таблицу блокировать или построчно.
V>Всегда решения принимает некая оценочная ф-ия (блок кода соответствующий) с какими-то граничными параметрами, в т.ч. эти границы могут зависеть от характера трафика и текущей степени "занятости" таблицы (а в серьезных системах текущая статистика/диагностика для телеметрии-контроля обязательно собирается, в т.ч. для изучения работы системы с целью её дальнейшего усовершенствования).
(Не будем пока вдаваться в то, что такое "характер трафика", и как устроена текущая степень занятости таблицы. Можно обсудить в отдельном топике, а то мы тут вообще утонем. Здесь пока обозначу проблематику такого подхода: для его применения нужно обосновать, что затраты на сбор статистики и просмотр её результатов не превышают экономию от выбора стратегии блокировки. Отвечать на это не надо, чтобы не захламоять дискуссию)
Странно, что исходно вы в ответ на вопрос про то, сколько будет стоить захват блокировок смело предположили, что а) при сканировании таблицы будет захвачена блокировка таблицы, и б) что для захвата этой блокировки в отсутствие конфликтов достаточно одной CAS операции. Оба предположения в общем случае неверны.

V>Код целиком не привели? (опять ржу че-та)
Нет, даже не упомянули про такие функции в вашем коде.

V>На это тебе уже ответили — ф-ия read из CRT тоже не умеет читать файл построчно, но с помощью этого read построчно прочитать файл элементарно.
V>С помощью уже показанного тебе кода нарисовать RO-RW замок — как два пальца об асфальт.
Ну, так нарисуйте. Не можете — сходите в википедию. Или в гитхаб — там такого добра навалом

V>Тебе надо было или нарисовать, или просто самому понять, как можно с помощью этих ср-в нарисовать подробно описанный до этого алгоритм (аж две разновидности), т.е. достаточно было обменяться сигналами с оппонентом "ОК, я это понял, едем дальше".
Что такое "подробно описанный алгоритм"? Вы про конверсию из read в write даже не упомянули. И про реентерабельность тоже — а ведь без неё ничего не взлетит.

V>Мде? ))
А то. У вас вызов acquireWrite после acquireRead приводит к дедлоку даже в отсутствие конфликтов, а вы печётесь о голодании писателей.


V>Его выражение на любом конкретном ЯП часто лишь мешает всей этой ненужной мишурой, это почему возникли и в определённых кругах популярны функциональные языки — банально из-за "синтаксического оверхеда" процедурных-объектных, код которых слишком "зашумлён".
Конечно. Можно и псевдокодом алгоритм описать.

V>Для особо одарённых еще раз — уровни изоляции не равны блокировкам.
Конечно не равны. Кто утверждал обратное?

V>Тебе уже дважды объясняли, как изоляция страницы для читателей может быть выполнена только через shared-блокировку её по чтению, через механизм COW.
V>Через это работают в т.ч. твои repetable read.
Repeatable read мсжет быть реализован через COW (который в мире СУБД называется MVCC), а может — и без него, при помощи только лишь блокировок. Как, впрочем, и serializable.

V>До смешного, тебе рассказывают об этом механизме уже несколько постов, а ты потом преподносишь repetable read как откровение.
V>Ситуация забавна — у тебя отсутствует сопоставление между названиями "блокировок" и реально происходящего в базе.
Эмм. Repeatable Read — это не название "блокировки", а уровень изоляции. Есть несколько возможных протоколов его реализации — и, в частности, построенный на блокировках, безо всякого COW.

V>Ознакомился, рассмотрена реализация специфичной хеш-таблицы для многопоточности, и?
Приведено описание кода операции "захватить блокировку". Приведены проблемы предыдущей реализации этой операции. Приведено предлагаемое решение этих проблем.
Можете сравнить со своей "одной interlocked операцией", и устыдиться.

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

V>Именно так.
V>"Фундаментальные" вещи, они именно такие.
V>Это те, через комбинаторику которых остальное "выводится".
Не, не выводится. Сериализуемость операций неассоциативна Из того, что вы показали одну сериализованную операцию, и вторую сериализованную операцию, не следует сериализованность произвольной комбинации этих двух операций.
Дьявол — в деталях.

V>Только не списками, а некоей иерархией, в статье "LOCKING WITH LESS LATCHING".
Нет там никакой иерархии.
V>Т.е. модель-то простая — введен однонаправленный граф отношений блокировок.
Где вы там увидели однонаправленный граф? В реализации списка блокировок? Там нет ничего про упорядочивание. Это просто список со специальным набором потокобезопасных операций над ним.
V>Я предлагал просто пронумеровать, помнишь?
Помню. И продолжаю хохотать.

V>В том коде в статье тоже на вид блокировки не смотрят, "совместимость" вычисляют тупо из нумерации их типа.
V>Вот это приплызд для тебя, вот это ты мне забавно опять возражаешь. ))
Гм. То есть фрагмент псевдокода "if (lock is incompatible with n_lock) вы проинтерпретировали как "вычисляют тупо из нумерации их типа"?
Если нет — то укажите, где именно вычисляется совместимость блокировок в статье.

S>>о которых у вас вообще не упомянуто
V>Например, когда я поправлял тебя, что если ты захватил страницу по shared-чтению, то тебе не требуется блокировать по чтению отдельные строки этой страницы.
V>И я был сильно удивлён, поправляя тебя в этих местах.
V>Ты ж ни в зуб ногой, как оно унутре может быть устроено...
Продолжаете бредить, противореча сами себе. Вот я в транзакции T1 "заблокировал по чтению" (acquire shared lock) на строку R1 страницы P1.
Как мы помним, перед этим мне надо "предотвратить монопольные блокировки страницы P1 конкурирующими транзакциями", или, по вашему, захватить shared lock на P1. Но раз я захватил shared lock на P1, то зачем мне тогда захватывать shared lock на P1:R1? А раз не надо, то зачем нам вообще такая штука, как shared row lock? Выходит, она вообще не существует, и перед тем, как прочесть какую-то строку, надо просто захватить страничную shared lock.
Ок. А как тогда мы поступим, когда конкурирующая транзакция T2 хочет захватить exclusive lock на строку R2 той же страницы P1? Ей, судя по всему, потребуется захватить какую-то блокировку на P1 — какую именно? Будет ли этот захват дожидаться окончания T1 или сразу поедет дальше?

V>Или по другой причине — потому что ты упоротый сноб, которому "имидж" важнее знаний.
Ну, вот и к открытому хамству перешли.

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

V>И что проблема в том коде конкретно вот здесь:
V>mutex_enter(lock_table->mutex)

V>Что самописными блокировками оперируют через глобальный на всю таблицу мьютекс.
V>О чем тебе тоже говорилось минимум дважды — что это плохой, негодный подход.
Погодите, вы сейчас о какой таблице? О таблице БД или о таблице блокировок? Не припомню в ваших постах хоть каких-то упоминаний таблиц или списков блокировок.

V>И заодно показывает, что ты ни хрена не понял из той статьи, бо люди озаботились ровно тем, чем сходу озаботился я — эффективностью реализации атомарного управления "блокировками".
Ну, и где же вы этим озаботились? Где у вас хоть в коде, хоть в тексте упоминание поиска конфликтующих блокировок, или выделения нового объекта-блокировки?
V>Собсно, статья только об этом и ни о чём больше.
Совершенно верно, статья именно об этом. Она иллюстрирует ровно вот эти моменты из моих постов, которые вы, как обычно, поскипали:

Причём очевидным образом эти ресурсы должны создаваться динамически: никто не создаёт заранее миллиарды семафоров для каждой строки в базе. И миллиарды очередей тоже заранее не создаёт.
Поэтому хоть захват блокировки, хоть постановка в очередь сопровождается отдельной операцией поиска/создания объекта, которая закрыта, естественно, ещё одной блокировкой.
То есть захват минимального row lock — это как минимум четыре интерлокед операции, и это на happy path, когда во всей системе ровно одна исполняемая транзакция.

И операция "прочесть строку" в коде исполнения запроса будет честно захватывать shared intent lock на страницу, а потом read lock на строку.
При этом каждый из этих захватов вовсе не будет сводиться к "одной interlocked операции", а будет перед CAS бегать по таблицам блокировок, да ещё и под критической секцией.

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


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

V>Теперь ты просто удобный манекен для демонстрации того, каким быть нельзя.


S>>Но вот за вами такой готовности незаметно — ни в этом топике, ни в каких других. У вас всегда наготове критика, переваливание ответственности на других, и смелые заявления "я бы сделал лучше".
V>Нормальные заявления в подходящих для этого местах.
Для таких заявлений подходят места вроде форумов домохозяек, и бары в кампусе — для охмурения доверчивых второкурсниц технических специальностей.
А в профильных форумах играет только код
V>Я же не просто говорил "там можно было сделать лучше", я озвучил — как именно.
Формулировка "реализация самописанных очередей задач" не является "как именно".

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

V>Показать, как произвольный такой список вообще реализуется для произвольной же иерархии вложенных друг в друга ресурсов.
Пока что показать у вас никак не получается. Увы. Ваш RO/RW во-первых, не работает, а во-вторых, никак не обобщается на минимально необходимый для иерархического ресурса набор из Shared, Exclusive, Intent Shared и Intent Exclusive.
Я уж не говорю про красивости вроде Update, Intend Update, и Shared with Intent Update.

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

V>Т.е., в других задачах, вполне вероятно (и оно так и есть) может быть другой список и блокировок, и отношений м/у ними — это часто еще зависит от характера задач и данных.
Конечно может. Но отрицать само существование прикладных видов блокировок — это близко к безумию.
V>В этом смысле блокировки в БД туповатенькие, конечно, т.к. про характер задач и данных не в курсе, поэтому релизуют самые общие и часто не самые эффективные алгоритмы, будучи рассмотренными для конкретных сценариев.
Для реализации именно SQL (т.е. select/update/insert/delete) "алгоритмы СУБД" особо и не улучшить.
Некоторые конкретные сценарии можно было бы сделать лучше (например, атомарное перемещение между счетами), но для этого нужно иметь другой набор операций, а не просто read / write.

V>Но общий принцип решения "задач о блокировках" — он, считай один.
И каков же этот "общий принцип"?

V>У меня пока одно затруднение — ученик отказывается учиться.
V>И не в том ученик уже возрасте, когда есть возможность надавить/заставить, через родителей, просто поругать и т.д. ))


V>Ничего не было скипнуто, ля врать-то. ))
Да ну?

V>Ты ведь уже shared-владешь страницей, т.е. можешь читать данные этой страницы "просто так".
Эмм, а откуда транзакция "знает", что уже shared-владеет страницей? В коде вашего семафора нет никакой информации о том, кто чем владеет.

V>Т.е., "законный" O(log(N)) будет при отсутствии всякой статистики.
Не, статистика не поможет вам выехать из O(log(N)). Она работает не так. Точнее, есть один тип индексов, построенный на знании об "островках" данных, но его придумали вот только пару лет тому, и ни в одной СУБД пока промышленно он не применяется. А о применении такой статистики, как вы говорите, в B/B+/B* деревьях я никогда не слышал.
Это интересно, если работает — пришлите ссылку на описание подхода.

V>Известно как — за счёт неких допущений несогласованности. ))
Это не ответ. Предположим, мы хотим гарантировать serializable. Какие блокировки будем захватывать при выполнении запроса?
Одиночный exclusive database lock не предлагать.

V>В дотнете:
Ну ок, release вы сделали. А как вы собираетесь сделать аналог acquire() для писателей?

Возвращаемся к главному вопросу: как выглядит код исполнения типичного запроса? Предположим, мы выполняем что-то вроде

select count(id) from sales s inner join city c on s.cityId=c.id where c.name = 'Севастополь' and s.Amount > 150

Можете набросать то, что будет исполняться движком СУБД? Если это будет императивный код с семафорами — что и когда будет захватываться и отпускаться.
Если это будет набор объектов-тасков — то какие это будут объекты-таски?

V>Я отвечаю на всё подряд в каждом посте, пока не надоедает.
А выглядит так, что отвечаете до тех пор, пока не натыкаетесь на описание вашего "залёта" (в вашей терминологии).

V>Вот это твоё постоянное замыливание, вся эта мышиная возня какая-то мелочная-дурацкая...
Ну где же моё-то? Замыливание постоянно только с вашей стороны.

V>Да ради бога, только у меня и в этой дисциплине длиннее, бо, сорри, но я тебя наблюдательнее где-то в бесконечное число раз.
Ну, давайте проверим, кто наблюдательнее. Вот вы где-то увидели в статье вычисление совместимости из нумерации блокировок, а я — нет. Покажите в ней это место, и мы вместе посмеёмся над моей наблюдательностью.

V>А как ты себе вообще представляешь "уметь разбираться в многопоточности"?
Цитирую:

с ходу ткнуть пальцем в код синхронизации со словами "у вас тут гонка".

V>Это как с языком программирования — если сможешь написать для некоего ЯП компилятор-интерпретатор — ты понял этот язык.
V>Не сможешь — еще не понял.
Не обязательно. Разработка компиляторов-интерпретаторов — отдельная дисциплина, к использованию языка отношения не имеющая. Ну, вот вы же, к примеру, считаете, что SQL понимаете, не так ли?
А для разработки "компилятора" этого языка вам нужно ещё очень много чего изучить. А в терминах времени пропасть вообще бесконечна — потому что вы и учиться-то не хотите, считая ваши рудиментарные знания достаточными.

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

V>Ты преподаешь ведущим специалистам с 30-тилетним стажем?
V>Сорри, но не верю.
Эмм, я же дал ссылку. Что мешает открыть её и посмотреть, что и кому я преподаю?

V>А может ты лекции читаешь студентам, т.е. минимум доцент?
Лекции тоже читаю. Но в чётных семестрах.
V>А на какую темы был диссер, почему не похвастался еще?
Покамест обходимся без диссера. Всему своё время.
V>Или ты там лаборант/практик?
V>А мне тут втирать опять изволишь?
Т.е. ссылка на конкретное расписание конкретных занятий называется "втирать"? Для чемпиона по внимательности это заявление выглядит неожиданным.

V>Тут же почти все твои собеседники имеют ВО, прекрасно в курсе, что лаборантами/практиками работают даже зеленые аспиранты, которые вот только сами ВУЗ закончили.
А то, работают.
V>Это таков был "последний аргумент?"
Это вообще не аргумент. Это иллюстрация разницы позиции "я разбираюсь в некоторой теме и готов вас научить" и позиции "я в некоторой теме дартаньян, а вы — говно".
V>Признаюсь, на этот пост я ответил целиком только чтобы дойти до этого места и тщательно здесь оттоптаться.
Да? Я подозревал, что вами движут какие-то низменные мотивы, но сомневался до последнего. Отличный каминг аут.

Здравствуйте, 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>Не въезжаете в механику работы управления блокировками в СУБД.

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

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

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

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