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


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

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

V>Именно поэтому мейнстримом уже относительно давно для серверных приложений является оборачивание вычислительных задач в объекты-таски пользовательского уровня, с управлением очередями задач из юзверского (по отношению к операционке) кода.
V>Это основная причина, из-за которой я утверждал, что ключевые слова async/await в дотнете не нужны.
А какова будет нотация описания пользовательских задач? Руками переписывать всё в state machine?
Я не уверен, что это будет нагляднее, чем код с async/await.

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

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

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

Что-то мне подсказывает, что вы опять отделаетесь общими словами.

V>И в чём у тебя проблема?
V>Если CONS способно связать пару узлов, то можно привязать и третий, и сорок третий.
Проблема — в деталях. Пока что у вас все рассуждения — уровня "процессор исполняет ассемблерные инструкции, поэтому нужно просто превратить программу в набор инструкций и их исполнить".

V>Забудь про базы и таблицы (это сильно мешает, смотрю), пронумеруй хоть от одного до ста некие уровни иерархий ресурсов и распиши себе.
Опять нумерация. Для каждого уровня иерархии потребуется свой объект ресурса. Вот вам кажется, что можно реализовать page lock так, как будто он блокирует сразу "пачку" единиц, а row lock их блокирует по одной.
Да, но это же только часть решения. В мире СУБД эта часть называется intent lock и да, перед захватом блокировки строки нужно захватить блокировку страницы. (Есть и альтернативные решения, но они слишком дорогие на практике и их никто не применяет).
Но вы-то пишете так, как будто это и есть решение для row lock, а меж тем строки — это отдельные ресурсы, и их захватывать надо тоже.
Причём очевидным образом эти ресурсы должны создаваться динамически: никто не создаёт заранее миллиарды семафоров для каждой строки в базе. И миллиарды очередей тоже заранее не создаёт.
Поэтому хоть захват блокировки, хоть постановка в очередь сопровождается отдельной операцией поиска/создания объекта, которая закрыта, естественно, ещё одной блокировкой.
То есть захват минимального row lock — это как минимум четыре интерлокед операции, и это на happy path, когда во всей системе ровно одна исполняемая транзакция.


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