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

V>>Ключевое здесь — уровни параллелизма операций скачут от много к одному и обратно.
S>Ключевое здесь — одного счёткчика недостаточно для описания реалистичной иерархии блокировое

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


S>Поятно, что внутри всё строится на каких-то простых примитивах. Достаточно, грубо говоря, одного вида синхро-объектов, чтобы реализовать любую систему блокировок.

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


S>Но из этих синхрообъектов, списков, массивов, и атомарных переменных придётся строить довольно таки сложный велосипед.

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

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

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

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

В простонародье это называют "асинхронщиной", но это поверхностное представление.
Асинхронные эти задачи только с т.ч. потоков ОС, но сами по себе выч. задачи, управляемые юзверским слоем, в своей логике исполнения в 99.99% синхронны.

Это основная причина, из-за которой я утверждал, что ключевые слова async/await в дотнете не нужны.
Коль механизм диспетчеризации отделён от логики разрабатываемой разработчиком программы, спрятан где-то унутре, то и нет смысла оперировать async-await, достаточно на уровне дотнета оперировать вычислительными потоками по принципу т.н. зеленых потоков.


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

И в чём у тебя проблема?
Если CONS способно связать пару узлов, то можно привязать и третий, и сорок третий.

Отношение блокировок различных по иерархии моделей сущностей в базе — это всегда изменение уровня параллелизма к ресурсу при движении от объектов верхнего уровня к нижним:
База -> таблица -> страница таблицы -> строка таблицы.
Подставь вместо "таблица" еще индекс по аналогии — не суть.

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


S>А так не работает.

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

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

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

V>>Ключевое здесь — уровни параллелизма операций скачут от много к одному и обратно.
S>Ключевое здесь — одного счёткчика недостаточно для описания реалистичной иерархии блокировое

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


S>Поятно, что внутри всё строится на каких-то простых примитивах. Достаточно, грубо говоря, одного вида синхро-объектов, чтобы реализовать любую систему блокировок.

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


S>Но из этих синхрообъектов, списков, массивов, и атомарных переменных придётся строить довольно таки сложный велосипед.

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

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

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

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

В простонародье это называют "асинхронщиной", но это поверхностное представление.
Асинхронные эти задачи только с т.ч. потоков ОС, но сами по себе выч. задачи, управляемые юзверским слоем, в своей логике исполнения в 99.99% синхронны.

Это основная причина, из-за которой я утверждал, что ключевые слова async/await в дотнете не нужны.
Коль механизм диспетчеризации отделён от логики разрабатываемой разработчиком программы, спрятан где-то унутре, то и нет смысла оперировать async-await, достаточно на уровне дотнета оперировать вычислительными потоками по принципу т.н. зеленых потоков.


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

И в чём у тебя проблема?
Если CONS способно связать пару узлов, то можно привязать и третий, и сорок третий.

Отношение блокировок различных по иерархии моделей сущностей в базе — это всегда изменение уровня параллелизма к ресурсу при движении от объектов верхнего уровня к нижним:
База -> таблица -> страница таблицы -> строка таблицы.
Подставь вместо "таблица" еще индекс по аналогии — не суть.

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


S>А так не работает.

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

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