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

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

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

V>Это и есть настоящий.
V>Тебя же не смущает, что семафор инициализируется произвольным значением своего счётчика?
Нет, не произвольным. Вы попробуйте сделать CreateSemaphore с отрицательным значением счётчика. Похоже, результат вас удивит.


V>А так же что в АПИ семафора можно изменять счётчик произвольно?
V>Или тебе требуется семафор непременно уровня ОС?
V>Проблемы с таким семафором я упомянул.
Проблемы с таким семафором начинаются с того, что в нём нет способа сделать счётчик отрицательным. Производительность и writers starvation — это уже так, вишенка на торте.
Поэтому приходится сделать вывод, что вы подразумеваете какой-то самописанный велосипед поверх системного семафора (или какого-то иного примитива синхронизации).
V>В конце привёл.
(Вздыхает) Я ожидал, что вы покажете, как реализовать read/write lock на основе семафора. А не то, как сделать slim-версию семафора поверх семафора ОС.
В приведённом вами коде по-прежнему нет API, которые бы дали изменять счётчик произвольно. По-прежнему единичные acquire и release.

V>В конце код.
Ничего подобного в коде в конце нету.

S>>Как будет выглядеть освобождение семафора писателем?

V>В зависимости от состояния очереди.
V>Если взята схема, где происходит управление очередями, то в этот момент очередь к ресурсу всего одна.
V>Если схема более "в лоб", то будет прибавление к семафору значения уровня параллелизма.
И сразу же получаем фейл — если в очереди стоит более 1 писателя, то они тут же побегут исполняться, не дожидаясь друг друга.

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

S>>Если мы сделаем опять инкремент на "большое значение", а в очереди несколько писателей, то может произойти совместный захват.
V>Очередь писателей одна.
V>Если эту очередь мы не обслуживаем явно, т.е. разводим хаос в потоках, тогда придётся сериализовать их через еще один семафор.
V>Собсно, "классическая" реализация RO-RW блокировки так и делается, но у неё есть серьёзные бока, о которых я упоминал.
Ок, я понял. "Классическая" реализация RO-RW блокировки не взлетела, несмотря на обещания сделать реализацию, которая не отличает читателей и писателей.
Теперь речь идёт как минимум о двух очередях для двух видов блокировок. Причём очереди — несимметричные, ведут себя по-разному для читателей и писателей.
Что и требовалось доказать.

S>>То есть у нас уже как минимум самописанный семафор (поверх какого-то механизма синхронизации ОС) +турникет.

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

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

V>ИМХО, разработчика разумного должно интересовать понимание механизмов, а не их имена собственные, розданные частными фирмами для подсистем своих поделий.
V>Тем более, что там всегда более-менее примитивно, не сложнее даваемого на 3-м курсе профильных специальностей.

Отлично. Давайте разбираться с механизмами.

S>>Давайте добавим в смесь update блокировки. Как вы реализуете их на одном семафоре, вместе с shared и exclusive?

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

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

V>Если тебе это сложно — смени род деятельности, какие проблемы?
У меня всё в порядке с родом деятельности. Вы просто теряете нить рассуждений. Сложность здесь означает не "сложность в понимании", а "сложность в исполнении". Количество инструкций, которые нужно выполнить перед тем, как сработает заветный LEA [EAX+EDX*16].

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

V>Поэтому, их так и не пишут, ес-но.


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

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

S>>Непонятно описываете.

V>Медитируй, там всё понятно.
Нет, плохо объясняете.

V>>>Этим же алгоритмом точно так же элегантно обслужишь отношение блокировок уровня строки и страницы.
S>>Это как это так? Я тупой, не понимаю, как устроен примитивы "захватить shared row lock", "отпустить shared row lock", "захватить exclusive row lock", "отпустить exclusive row lock" в такой системе.

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

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

V>Пусть будет домашнее задание.
V>Я и так слишком подробно всё описал.
Ну-ну. Вы заметили закономерность: как только доходит до конкретики, вы незамедлительно обвиняете собседника в тупости и сливаетесь?
И про составление плана запроса из предкомпилированных кубиков — ровно так же: годы идут, а вы до сих пор не попробовали дотянуть свою идею до хотя бы псевдокода.
Неужто уже поняли, что не взлетит?

V>Нарисуй очереди, ресурс, стрелки, писателей-читателей, протрассируй работу, и всё станет понятно.
V>Например, студентам понятно.
Отож. Просто когда мы будем рисовать ресурс, стрелки, писателей, читателей, и апдейтеров, окажется, что чудес не бывает, и невозможно свести все виды блокировок к одной плоской модели.
К примеру, добавление update lock заставит вас перепроектировать систему очередей и правил их обслуживания. Да, где-то внутри будут какие-то простые примитивы — или там ожидание на событиях, или CAS операции и кооперативщина. Но обойтись без понимания того, что такое intent lock, и чем update lock отличается от exclusive lock, не получится.


S>>Ну, например, просто потому, что нет метода "заменить текущее значение семафора на -x"

V>Есть, соотв. сигнатуру ВинАПИ дал выше.
Ох уж мне эти сказочники. Попробуйте сделать Release с отрицательным значением счётчика, а я на вас посмотрю.

V>Защити код обращения к семафору критической секцией и это можно будет промоделировать на семафорах уровня ОС.
Брр.

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

V>Уверен, ты пока не пробовал.
V>Попробовал бы — не писал бы того, что писал.


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

V>Бо иначе как тебе в следующий раз говорить с придыханием о своей любимой эзотерике, доступной лишь посвящённым?
Чего? Какой ещё эзотерике? Нет никакой эзотерики.

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

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

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

V>Это и есть настоящий.
V>Тебя же не смущает, что семафор инициализируется произвольным значением своего счётчика?
Нет, не произвольным. Вы попробуйте сделать CreateSemaphore с отрицательным значением счётчика. Похоже, результат вас удивит.


V>А так же что в АПИ семафора можно изменять счётчик произвольно?
V>Или тебе требуется семафор непременно уровня ОС?
V>Проблемы с таким семафором я упомянул.
Проблемы с таким семафором начинаются с того, что в нём нет способа сделать счётчик отрицательным. Производительность и writers starvation — это уже так, вишенка на торте.
Поэтому приходится сделать вывод, что вы подразумеваете какой-то самописанный велосипед поверх системного семафора (или какого-то иного примитива синхронизации).
V>В конце привёл.
(Вздыхает) Я ожидал, что вы покажете, как реализовать read/write lock на основе семафора. А не то, как сделать slim-версию семафора поверх семафора ОС.
В приведённом вами коде по-прежнему нет API, которые бы дали изменять счётчик произвольно. По-прежнему единичные acquire и release.

V>В конце код.
Ничего подобного в коде в конце нету.

S>>Как будет выглядеть освобождение семафора писателем?

V>В зависимости от состояния очереди.
V>Если взята схема, где происходит управление очередями, то в этот момент очередь к ресурсу всего одна.
V>Если схема более "в лоб", то будет прибавление к семафору значения уровня параллелизма.
И сразу же получаем фейл — если в очереди стоит более 1 писателя, то они тут же побегут исполняться, не дожидаясь друг друга.

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

S>>Если мы сделаем опять инкремент на "большое значение", а в очереди несколько писателей, то может произойти совместный захват.
V>Очередь писателей одна.
V>Если эту очередь мы не обслуживаем явно, т.е. разводим хаос в потоках, тогда придётся сериализовать их через еще один семафор.
V>Собсно, "классическая" реализация RO-RW блокировки так и делается, но у неё есть серьёзные бока, о которых я упоминал.
Ок, я понял. "Классическая" реализация RO-RW блокировки не взлетела, несмотря на обещания сделать реализацию, которая не отличает читателей и писателей.
Теперь речь идёт как минимум о двух очередях для двух видов блокировок. Причём очереди — несимметричные, ведут себя по-разному для читателей и писателей.
Что и требовалось доказать.

S>>То есть у нас уже как минимум самописанный семафор (поверх какого-то механизма синхронизации ОС) +турникет.

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

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

V>ИМХО, разработчика разумного должно интересовать понимание механизмов, а не их имена собственные, розданные частными фирмами для подсистем своих поделий.
V>Тем более, что там всегда более-менее примитивно, не сложнее даваемого на 3-м курсе профильных специальностей.

Отлично. Давайте разбираться с механизмами.

S>>Давайте добавим в смесь update блокировки. Как вы реализуете их на одном семафоре, вместе с shared и exclusive?

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

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

V>Если тебе это сложно — смени род деятельности, какие проблемы?
У меня всё в порядке с родом деятельности. Вы просто теряете нить рассуждений. Сложность здесь означает не "сложность в понимании", а "сложность в исполнении". Количество инструкций, которые нужно выполнить перед тем, как сработает заветный LEA [EAX+EDX*16].

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

V>Поэтому, их так и не пишут, ес-но.


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

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

S>>Непонятно описываете.

V>Медитируй, там всё понятно.
Нет, плохо объясняете.

V>>>Этим же алгоритмом точно так же элегантно обслужишь отношение блокировок уровня строки и страницы.
S>>Это как это так? Я тупой, не понимаю, как устроен примитивы "захватить shared row lock", "отпустить shared row lock", "захватить exclusive row lock", "отпустить exclusive row lock" в такой системе.

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

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

V>Пусть будет домашнее задание.
V>Я и так слишком подробно всё описал.
Ну-ну. Вы заметили закономерность: как только доходит до конкретики, вы незамедлительно обвиняете собседника в тупости и сливаетесь?
И про составление плана запроса из предкомпилированных кубиков — ровно так же: годы идут, а вы до сих пор не попробовали дотянуть свою идею до хотя бы псевдокода.
Неужто уже поняли, что не взлетит?

V>Нарисуй очереди, ресурс, стрелки, писателей-читателей, протрассируй работу, и всё станет понятно.
V>Например, студентам понятно.
Отож. Просто когда мы будем рисовать ресурс, стрелки, писателей, читателей, и апдейтеров, окажется, что чудес не бывает, и невозможно свести все виды блокировок к одной плоской модели.
К примеру, добавление update lock заставит вас перепроектировать систему очередей и правил их обслуживания. Да, где-то внутри будут какие-то простые примитивы — или там ожидание на событиях, или CAS операции и кооперативщина. Но обойтись без понимания того, что такое intent lock, и чем update lock отличается от exclusive lock, не получится.


S>>Ну, например, просто потому, что нет метода "заменить текущее значение семафора на -x"

V>Есть, соотв. сигнатуру ВинАПИ дал выше.
Ох уж мне эти сказочники. Попробуйте сделать Release с отрицательным значением счётчика, а я на вас посмотрю.

V>Защити код обращения к семафору критической секцией и это можно будет промоделировать на семафорах уровня ОС.
Брр.

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

V>Уверен, ты пока не пробовал.
V>Попробовал бы — не писал бы того, что писал.


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

V>Бо иначе как тебе в следующий раз говорить с придыханием о своей любимой эзотерике, доступной лишь посвящённым?
Чего? Какой ещё эзотерике? Нет никакой эзотерики.