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

V>>Или крайне простой велосипед — очередь.
V>>Это зависит от способа представления вычислительных задач.
S>Можно обсудить оба способа.

Строго говоря, оба раза способ примерно один и тот же (с точностью до подробностей реализации).

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


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

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

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


S>Предлагаете заведомо неадекватное решение, да ещё и неполное?

Какое именно неадекватное решение я предлагал и почему оно неполное-то? ))

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

Например (опять про очереди) классическая межпоточная очередь на условной переменной сливает самописной моей реализации на комбинации lock-free алгоритмов и примитива синхронизации ОС (когда-то же потоку-приёмнику в спячку уходить надо в отсутствии задач) где-то под 50 раз в тестах пропускной способности.

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

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

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

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

==========
Остальное дочитаю и отвечу потом, пока мест в этом посте ничего вызывающего не встретилось. )

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

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

Вот как выше — ты задал сразу пачку вопросов не по существу. Но отвечать же что-то надо? ))

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

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

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

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

V>Речь была про то, что характеристики такого решения будут далеки от желаемых.
Покажите решение с характеристиками, которые близки к желаемым.
V>А ты, насколько я заметил, вместо рассуждений о соотвествии встроенных ср-в ОС задачам обыгрывания нетривиальных иерархий блокировок, рассуждаешь "там всё сложно" (С).
Эмм, меня вообще не очень интересует соответствие встроенных в ОС средств. Интересует совершенно банальный вопрос: как будет выглядеть код выполнения запроса.
Можно показать это на lock-free, можно на примитивах ОС, можно на какой-то комбинации. Делов-то. Вы утверждали, что вам хватит одной интерлокед-операции для скана таблицы. Мне это утверждение кажется очевидной чушью, но я могу заблуждаться. Поэтому мне хочется увидеть примерный код того, как это чудо будет реализовано. А вы вместо того, чтобы показать своё решение, растекаетесь мыслью по древу, пытаясь меня запугать очередями, СМО, и прочими не относящимися к задаче темами.

V>Когда/если будешь "упражняться" — стоит держать в голове, что блокировки не цель, но лишь способ упорядочивания изначально хаотичного конкурентного трафика заявок.
V>Т.е. целью является именно диспетчеризация заявок, где "блокировки" — вспомогательный механизм.
Целью является обеспечение ACID. Я не вижу хорошего способа его обеспечить без блокировок.

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

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

Это не столько от автомата зависит, сколько от качества самого кофе. На том же ГПН одно время был вполне сносный кофе (сейчас испортился). Сейчас в моей деревне, внезапно, более менее приличный кофе в Mix-точке (дорогой автомат) за 120р и, внезапно, в Ярче! (автомат) за 39р. А в местах с рожковой кофеваркой кофе от посредственного до откровенно отвратного.

S>Ну, если не считать домашних автоматов — мой, к примеру, варит кофе не сильно хуже, чем в средней кофейне.

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

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

V>Да не можешь ты никому преподавать про гранулярность блокировок в отсутствии владения дисциплиной СМО, бо блокировки — это исключительно про очереди к ресурсам.

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

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

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

Для описания многоуровневого кеша необходимо ввести петлю — зациклить поток отказов обратно в поток заявок.
https://cf.ppt-online.org/files/slide/c/cERdrLYwlXVxoWnHCi50Mp8D1kUtq7v6gZj9P3/slide-10.jpg

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

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


НС>А современные распределенные системы много много сложнее процессора с кешем, поэтому теории СМО там делать нечего.

И прекрасно СМО описываются.
В т.ч. распределённые.

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

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

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

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

V>Другого более адекватного как матаппарата, так и аппарата иммитационного моделирования на сегодня всё-равно нет.

А никто и не говорит что он есть. Поэтому в реальности такие задачи и решают симуляцией, а теория СМО с ее аналитическими моделями вызывает только академический интерес.

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

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

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


НС>При этом ровно те же задачи легко решаются простейшей симуляцией.

Ну так какая задача стояла? ))

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

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


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

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

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

V>А какой ожидался "полезный выхлоп" от построения модели и изучения её характеристик?

Предсказание поведения.

V>Это ж не докторская, кандидатская.

Там и докторская одна была.

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

V>>Какое именно неадекватное решение я предлагал и почему оно неполное-то? ))
S>Неадекватное решение — реализация набора видов блокировок в СУБД через самописанный семафор

Это адекватное решение и именно так СУБД работают.


S>Неадекватное оно по вашим же словам.

Это ты придумывать изволишь.


S>А неполное оно потому, что вы не показали ни API, ни реализацию такого семафора.

Было показано:
http://www.rsdn.org/forum/flame.comp/8108567.1

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


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

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


V>>А ты, насколько я заметил, вместо рассуждений о соотвествии встроенных ср-в ОС задачам обыгрывания нетривиальных иерархий блокировок, рассуждаешь "там всё сложно" (С).
S>Эмм, меня вообще не очень интересует соответствие встроенных в ОС средств. Интересует совершенно банальный вопрос: как будет выглядеть код выполнения запроса.

Как код реализации СУБД? ))
Ты опять задаёшь вопросы не по существу, в рамках обсуждений форума мы можем рассмотреть лишь отдельные моменты, но ты и их понять и продвинуться на шажок дальше пока не в состоянии.


S>Можно показать это на lock-free, можно на примитивах ОС, можно на какой-то комбинации. Делов-то.

Это уже.


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

Это ты опять невнимателен.


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

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



S>Поэтому мне хочется увидеть примерный код того, как это чудо будет реализовано. А вы вместо того, чтобы показать своё решение, растекаетесь мыслью по древу, пытаясь меня запугать очередями, СМО, и прочими не относящимися к задаче темами.

Ну и зачем так подставляться под пеняние на феномен блаба? ))

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

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


S>Целью является обеспечение ACID.

Опять какой-то бред несёшь, просто не охота засорять пост десятками смайликов рука-лицо.

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


S>Я не вижу хорошего способа его обеспечить без блокировок.

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

Вот я ХЗ что уже думать — или ты не знал значение термина "блокировка" и вводишь оппонента в заблуждение, неточно выражая свои мысли, или ты не понимаешь даже азов, что в СУБД, наоборот, делаются некие допущения, ухудшающие ACID, что приводит как к несогласованности, так и к отказам/конфликтам (иногда повторным запускам запросов/сканов и т.д. и т.п.)

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

Давай, плиз, выражайся яснее и читай ответы внимательней.

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

НС>Не знаю что у тебя там дома, но вряд ли дорогущий профессиональный автомат варит хуже него.
У меня — банальная капсульная машинка Nespresso с капучинатором.
НС>Все дело, еще раз повторюсь, в зернах (и в молоке). А все эти тонкости приготовления, по крайней мере стандартного эспрессо и напитков на его основе, не сильно далеко ушли от проводов из бескислородной меди.

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

Повторюсь: это не исключает каких-то локальных аномалий, когда ставится не только дорогущий автомат, но и выбираются качественные зёрна, хорошее молоко, а автомат холят и лелеют.
Но в наших краях это не особо бьётся с идеей минимизации костов; а те, кто гонится не за ценой, а за качеством, обычно почему-то нанимают баристу и ставят рожковую машину. Не знаю, что там сняли с производства у коллеги vdimas, а у нас всё прекрасно комплектуется свежими машинками из примерно этого каталога: https://www.lavazza.it/it/business/bar/attrezzature-per-estrazione.html

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

V>Это адекватное решение и именно так СУБД работают.
Нет. Во всех СУБД, которые поддерживают row locking, блокировка строки и блокировка страницы делается через разные ресурсы, а не через один семафор.

S>>Неадекватное оно по вашим же словам.
V>Это ты придумать изволишь.
Цитирую:

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

V>Было показано:
V>http://www.rsdn.org/forum/flame.comp/8108567.1
V>И там же ты оставил мой процитированный псевдокод, который позволяет добавить к семафору произвольную операцию.
После добавления к семафору "произвольной операции" придётся ещё допилить код выбора между продолжением и ожиданием.
В вашем простом примере acquire() полагается на то, что одиночный release освободит достаточно ресурсов для успешного захвата, поэтому после _sema.acquire() можно просто выйти.

V>Показано.
Где? Никакого кода, кроме простейшего легковесного семафора поверх семафора ОС, не приведено.

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

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

V>Это уже.
Нет.

V>Это ты опять невнимателен.
Мне цитату привести?

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

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

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

Транзакция А захватывает shared lock на запись номер 3 на странице 42. Выполняем Page(42).acquire(1), успешно.
Транзакция B захватывает shared lock на запись номер 5 на странице 42. Выполняем Page(42).acquire(1), успешно.
Транзакция C захватывает shared lock на страницу номер 42. Выполняем Page(42).acquire(8), встаём в ожидании — косяк: ожидался успешный захват. Отменяем транзакцию C.
Завершаем транзакцию B.
Транзакция D захватывает exclusive lock на запись номер 3 на странице 42. Выполняем Page(42).acquire(1), успешно. Косяк: ожидался отказ или ожидание окончания транзакции A. Отменяем транзакцию D.

Транзакция A продолжает работу, захватывает shared lock на записи номер 4, 5, 6, 7, 8, 9, 10 при помощи Page(42).acquire(1) — успешно. Хотим захваттить shared lock на запись №11. Упс — кончился уровень параллелизма, встаём в дедлок, т.к. остальные блокировки захвачены нашей же транзакцией. Нет, так нельзя, надо увеличивать уровень параллелизма до MAXPAGERECORDS.

В общем, предлагаемый вами механизм заведомо неполон. Его можно допилить до требуемого уровня функциональности, но, повторюсь уже в третий раз, вы получите ровно те же блокировки, которые мы наблюдаем в промышленных СУБД. И их виды, и их иерархию. И код исполнения запроса будет точно таким же, как у всех — внутрь цикла сканирования мы будем вставлять вызовы _lockManager.AcquireSharedLock(_rowID).
Если вы попробуете на коленке набросать код этого метода, то поймёте, о чём я говорю.

V>Заведомый ACID можно обеспечить исключительно и только одним глобальным мьютексом, через сериализацию доступа.
Ну конечно же нет. Почитайте любой учебник по СУБД. Вас не настораживает, что блокировочники на уровне изоляции serializable не делают один глобальный мьютекс на базу?
Глобальная блокировка является достаточным, но вовсе не необходимым условием для serializability. Есть разные варианты протоколов сериализации транзакций, и все они в первую очередь добиваются именно сериализуемость.

V>Требуется, наоборот, обеспечить уровни изоляции худшие, чем сериализованный, с целью увеличения уровня конкурентности системы.
Для начала разберитесь с serializable.

V>Это если ты верно используешь термин "блокировка" в IT, где этот термин подразумевает исключительное владение ресурсом.
В СУБД блокировки бывают не только исключительными. Блокировка означает некоторую степень владения ресурсом.

V>Вот я ХЗ что уже думать — или ты не знал значение термина "блокировка" и вводишь оппонента в заблуждение, неточно выражая свои мысли, или ты не понимаешь даже азов, что в СУБД, наоборот, делаются некие допущения, ухудшающие ACID, что приводит как к несогласованности, так и к отказам/конфликтам (иногда повторным запускам запросов/сканов и т.д. и т.п.)
Для начала рекомендую ознакомиться с общепринятым определением, раз уж вы взялись рассуждать об устройстве СУБД: https://ru.wikipedia.org/wiki/%D0%91%D0%BB%D0%BE%D0%BA%D0%B8%D1%80%D0%BE%D0%B2%D0%BA%D0%B0_(%D0%A1%D0%A3%D0%91%D0%94)
Далее, вам нужно повторно изучить раздел "изоляция транзакций" в более-менее любом учебнике, и разобраться, почему "допущения, ухудшающие ACID", не обязательно приводят ни к несогласованности, ни к отказам/конфликтам.
Например, рассмотрите классическую задачу атомарного перевода денег между счетами, и убедитесь, что repeatable read достаточно для обеспечения согласованности данных в этой задаче.
Если после чтения Дейта и Бернстайна не выходит понять, как так получается — почитайте Гарсиа-Молина или хотя бы Сьоре.

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

V>Давай, плиз, выражайся яснее и читай ответы внимательней.

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

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

Почему?

S> или какая-нибудь двух-четырёх рожковая Лавацца.

У тебя дома ведь не "какая-нибудь двух-четырёх рожковая Лавацца", верно? Тем не менее кофе оттуда тебя устраивает.

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

НС>Это не столько от автомата зависит, сколько от качества самого кофе. На том же ГПН одно время был вполне сносный кофе (сейчас испортился). Сейчас в моей деревне, внезапно, более менее приличный кофе в Mix-точке (дорогой автомат) за 120р и, внезапно, в Ярче! (автомат) за 39р. А в местах с рожковой кофеваркой кофе от посредственного до откровенно отвратного.

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

S>>Ну, если не считать домашних автоматов — мой, к примеру, варит кофе не сильно хуже, чем в средней кофейне.

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

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

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

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

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

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

S>Но автомат обычно ставят не для того, чтобы он был дорогущим, а чтобы минимизировать косты. Из этого обычно как раз и вытекает соответствующее качество зёрен и молока.

В том то и дело — зарабатывать хотят все, даже те, кто в кофе не разбираются.

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

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

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

S>> или какая-нибудь двух-четырёх рожковая Лавацца.

НС>У тебя дома ведь не "какая-нибудь двух-четырёх рожковая Лавацца", верно? Тем не менее кофе оттуда тебя устраивает.

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

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

НС>>У тебя дома ведь не "какая-нибудь двух-четырёх рожковая Лавацца", верно? Тем не менее кофе оттуда тебя устраивает.
I> Дома вместо 400 порций в день будет 400 порций в год. Соответсвенно автомат не ушатывается так быстро. А еще и чистится гораздо чаще, чем раз в год. И кофе можно засыпать мелкими пакетами, тогда он всегда самый свежий.

Ну да. Ты к чему это написал?

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

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

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

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

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

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

НС>>Не знаю что у тебя там дома, но вряд ли дорогущий профессиональный автомат варит хуже него. Все дело, еще раз повторюсь, в зернах (и в молоке). А все эти тонкости приготовления, по крайней мере стандартного эспрессо и напитков на его основе, не сильно далеко ушли от проводов из бескислородной меди.
I> Тонкости приготовления как раз важны.

Или нет.

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

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

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

V>>Это адекватное решение и именно так СУБД работают.
S>Нет. Во всех СУБД, которые поддерживают row locking, блокировка строки и блокировка страницы делается через разные ресурсы, а не через один семафор.

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

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

Я:
— твоё утверждение ложно, бо в СУБД широко используют именно самописные семафоры.

Синклер:
— нет, блокировка строки и блокировка страницы делается через разные ресурсы, а не через один семафор.

Я:
— а как соотносятся твои "разный" (в плане экземпляров) и "самописный"?
— и почему "блокировка" делается через "ресурсы"? ))

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

Насчёт "ресурсов" буду считать, что ты оговорился.
Если нет — вот одна из первых ссылок в гугле, просто прочти первый абзац, там сходу понятно, что принято называть "ресурсом" в СМО:
https://cyberleninka.ru/viewer_images/16416395/f/1.png

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

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

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

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

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

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

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


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

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

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

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

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



S>>>Неадекватное оно по вашим же словам.
V>>Это ты придумать изволишь.
S>Цитирую:
S>

S>Одно но — на многопроцессорной машине в режиме вытесняющей многозадачности наших "очередей" нет, есть очереди уровня ОС, поэтому возможно голодание писателей, т.к. даже при ограничении доступа к ресурсу счётчиком 1, его могут захватить конкурентные потоки-читатели.

1. Где конкретно здесь про адекватность моего решения?
Это про адекватность дефолтного.
Если ты хотя бы из банального любопытства никогда ранее не интересовался алгоритмом RO-RW блокировки, то мог бы найти и ознакомиться на многих углах в инете.

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


V>>Было показано:
V>>http://www.rsdn.org/forum/flame.comp/8108567.1
V>>И там же ты оставил мой процитированный псевдокод, который позволяет добавить к семафору произвольную операцию.
S>После добавления к семафору "произвольной операции" придётся ещё допилить код выбора между продолжением и ожиданием.

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

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

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


S>В вашем простом примере acquire() полагается на то, что одиночный release освободит достаточно ресурсов для успешного захвата, поэтому после _sema.acquire() можно просто выйти.

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

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

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


V>>Показано.
S>Где? Никакого кода, кроме простейшего легковесного семафора поверх семафора ОС, не приведено.

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

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

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

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


V>>Как код реализации СУБД? ))
S>Именно.

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


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

С херна ли эффективнее существующих?
Кто тебе такое обещал?

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

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

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


Возвращаясь ко встроенным примитивам синхронизации — дело не только в дороговизне вызовов АПИ ОС поверх защищённой памяти, еще я раскрыл проблематику турникета, и, вроде бы, вполне однозначно, понять неверно там просто никак.

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


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

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

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

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

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


V>>Это ты опять невнимателен.
S>Мне цитату привести?

Да, и еще раз да.
Заодно сам еще раз внимательно перечитаешь.


V>>Ну так и перепроверил бы себя, что именно утверждалось.
V>>А то мне на каждый абзац здесь руку-лицо ставить надо.
S>Ок. Цитируем:
S>

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

И?
Одна на таблицу.
До этого одна на базу.
До этого одна на схему.
До этого минимум одна на входной механизм самописных очередей задач.
До этого на пул запросов, на ресурсы, требуемые для работы хотя бы парсера и валидации SQL, составления плана запроса согласно текущей схемы базы и т.д. и т.п.

Но в дефолтном алгоритме RO-RW блокировки аж три семафора, три недешёвых вызова АПИ ОС только на реализацию всего двух состояний СМО всего одного уровня из иерархии.
Разве не ого? ))

А если состояний "ячейки" СМО более одного (как ты там упоминал еще виды блокировок) — то и вовсе по-дефолту обычно делают на условной переменной, со всеми её suspicion wake up и чудовищной вероятности столкновения потоков на единственном мьютексе, обслуживающем эту условную переменную.


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

8 будет если на данном уровне иерархии ровно 8 фактических shared-владений.
А если одно?
А если ни одного?
Ты там цикл не видел разве в псевдокоде обновления счётчика?


S>Транзакция A продолжает работу, захватывает shared lock на записи номер 4, 5, 6, 7, 8, 9, 10 при помощи Page(42).acquire(1) — успешно.

Зачем?
Ты ведь уже shared-владешь страницей, т.е. можешь читать данные этой страницы "просто так".
Это тогда надо заходить на страницу под другой дисциплиной блокировки, например, "я могу блокировать с разными дисциплинами произвольные твои строки конкуретно", и тогда страница не пустит shread-RO "клиентов" к себе.

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

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

А текущая страница для shared RO-заявок переходит в режим фантома и будет жить до тех пор, пока ею shared-владеют, потом тихо умрёт.


S>Хотим захваттить shared lock на запись №11. Упс — кончился уровень параллелизма, встаём в дедлок

Здесь опять путаешь уровни иерархий.
Говорил же тебе — тупо пронумеруй, меньше вероятность ошибиться. ))


S>Нет, так нельзя, надо увеличивать уровень параллелизма до MAXPAGERECORDS.

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


S>В общем, предлагаемый вами механизм заведомо неполон.

В общем, я пока не вижу понимания даже на 10%.
Мне пока кажется, что ты уже понял про "гибкий" семафор, твой тон в этой области снизился, будем считать это за признаки понимания, ОК.

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

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

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

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

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


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

Не, мистер Блейн, с "промышленными" СУБД я не спорил, я тебе их объясняю, бо ты путал блокировки и уровни изоляции.
Я отделяю для тебя мух от котлет.

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


S>И их виды, и их иерархию. И код исполнения запроса будет точно таким же, как у всех — внутрь цикла сканирования мы будем вставлять вызовы _lockManager.AcquireSharedLock(_rowID).
S>Если вы попробуете на коленке набросать код этого метода, то поймёте, о чём я говорю.

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

Рановато, мистер Блейн, фокус не удался.
"На коленке" я жду от тебя куда как более примитивную часть этого кода — простое управление shared-exclusive доступом ко всего одному ресурсу, т.е. очень простой СМО из двух состояний.

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

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


V>>Заведомый ACID можно обеспечить исключительно и только одним глобальным мьютексом, через сериализацию доступа.
S>Ну конечно же нет.

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

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


S>Почитайте любой учебник по СУБД.

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


S>Вас не настораживает, что блокировочники на уровне изоляции serializable не делают один глобальный мьютекс на базу?

Это смотря что транзакция делает, т.е. на каком уровне иерархии работает.
Exclusive lock на уровне конкретной таблицы — это та самая сериализация доступа к этой таблице.


S>Глобальная блокировка является достаточным, но вовсе не необходимым условием для serializability.

Опять та же ошибка — зависит от уровня иерархии оперируемой сущности.
Еще раз — пронумеруй, будешь меньше путаться.


V>>Требуется, наоборот, обеспечить уровни изоляции худшие, чем сериализованный, с целью увеличения уровня конкурентности системы.
S> Для начала разберитесь с serializable.

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

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


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

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

В русскоязычном IT "просто блокировка" означает blocking lock на английском.


S>Далее, вам нужно повторно изучить раздел "изоляция транзакций" в более-менее любом учебнике, и разобраться, почему "допущения, ухудшающие ACID", не обязательно приводят ни к несогласованности, ни к отказам/конфликтам.

"Не обязательно" не канает.
Речь же о статистике-вероятности.

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

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

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

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

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

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

В этом смысле разработчики СУБД дают прикладным разработчикам набор "ср-в" и умывают руки.
Мол, ты же сам виноват, что забыл защитить переменную мьютексом, как-то так. ))


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

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


S>Если после чтения Дейта и Бернстайна не выходит понять, как так получается — почитайте Гарсиа-Молина или хотя бы Сьоре.

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



S>Поймите, бредовость вашего утверждения очевидна даже без копания в деталях

Какого именно утверждения?


S>если бы всё было так, как вы говорите, то никакие системы резервирования авиабилетов или банковской автоматизации не работали бы без "одного глобального мьютекса", что означало бы черепашью скорость проведения транзакций.

Ууу, как всё запущено. ))

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

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

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

И да, при попытке фактического резервирования repetable read уже не катит, упс?

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

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

НС>>>У тебя дома ведь не "какая-нибудь двух-четырёх рожковая Лавацца", верно? Тем не менее кофе оттуда тебя устраивает.
I>> Дома вместо 400 порций в день будет 400 порций в год. Соответсвенно автомат не ушатывается так быстро. А еще и чистится гораздо чаще, чем раз в год. И кофе можно засыпать мелкими пакетами, тогда он всегда самый свежий.

НС>Ну да. Ты к чему это написал?

Очевидно, вот твое утверждение
"У тебя дома ведь не "какая-нибудь двух-четырёх рожковая Лавацца", верно? Тем не менее кофе оттуда тебя устраивает."

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