Здравствуйте, 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>Давай, плиз, выражайся яснее и читай ответы внимательней.