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

V>>Далее я требую объяснения трижды тобой повторённого "это бред".
V>>Итак?..
S>Что "итак"? В чём вопрос-то?

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


S>Почему нельзя обойтись одной операцией Interlocked.CompareExchange? Посмотрите в код хотя бы того же MySQL. Там как бэ делается дофига чего, помимо "одной интерлокед операции".

Я и смотрел, в отличие от тебя.
Для тебя инфа по той ссылке — та самая одноразовая рыбка, которой тебя угостили.
Через единицы дней после прочтения и запаха не останется.
А учиться ловить рыбу тебе лень. ))

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

Задачей же инженера является не просто приобретение знаний в результате исследований, но непосредственное использование добытых знаний в конкретном продукте.
И знаниями, напротив, инженеры в кап.модели экономики делятся крайне неохотно, бо работодатель прямо запрещает.
Ну и, про "обособленности феномена" речи тоже обычно нет — инженер обычно работает над комплексом технических взаимодействующих проблем.

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

Мне иногда кажется в общении с тобой (с твоими посыланиями нахер DDD, с вопросами "а почему это вдруг пакет о программе знает, а программа о пакете нет?", с твоей неспособностью обсуждать никакие блокировки и вообще межпоточное взаимодействие в принципе), что с тобой надо разговаривать как с ребёнком, т.е. каждое объяснение начинать вообще с 0-ля.
Отсутствуют порой какие совсем базовые представления о том, как всё устроено и работает.

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

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

Ну понятное дело, тут сам бог велел взять тот код и начать над ним всячески измываться. ))


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

Дальше не надо было бегать.
Был вполне понятный пост:
http://www.rsdn.org/forum/flame.comp/8108421.1

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

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

Поэтому, какие в опу "таблицы", когда речь о реализации неких дисциплин диспетчеризации?
Разве некоему мьютексу требуется "знать" что там с помощью него мутуально-эксклюзивно захватывают? ))

Так и здесь.
Для режимов работы "локов" требовалось сформулировать ТЗ.
А кто там будет эти локи и как использовать — это уже другой уровень.
Я увидел очередные твои зияющие пробелы именно на этом уровне.

Мои попытки вернуть тебя на грешную землю, мол, те вещи, которые ты преподносишь как некие "знания" для юзверя СУБД, для данного уровня являются не более чем ТЗ ты тупо игноришь, т.е. опять не понимаешь, что тебе говорят и почему именно так. Информация классически не задерживается при отсутствии понимания.

В общем, предлагалось ТЗ формализировать и провести его классический анализ.
Это более чем обычный ход работ при проектировании чего угодно.

Пример RO/RW был приведён.
Ни само описание задачи RO/RW, ни его классическая реализация не были приведены по упомянутой там же причине — они общедоступны, т.е. считаем, что оно уже есть в контексте.
Т.е. можно рассматривать отдельные моменты работы предложенной к рассмотрению реализации поверх выталкивающей многозадачности.

Но у меня возникло впечатление, что я разговаривал с забором. ))

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

И зачем тебе еще одна рыба?
Через пару дней всё-равно в голове опять пусто будет.


S>В том-то и дело, что в атомарно изменяемой переменной не сохранишь весь список действующих на данный момент блокировок.

Почему ты решил, что надо хранить весь список?
Почему ты вообще пытаешься перескакивать этапы проектирования?

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


S>А его надо где-то держать и своевременно обновлять — иначе невозможно реализовать ни реентерабельность, ни конверсию локов, ни детектирование дедлоков.

Очередное ЧТД.
Для всего этого не нужны полные списки действующих "локов".
10 действующих локов какого-ти типа равны одному действующему локу этого же типа.


S>Именно поэтому так, как вы пишете, не делает в СУБД никто.

Вот, именно поэтому ты трепло, бо ты понятия не имеешь как пишут СУБД и вообще любые подобные системы.
Из пальца насасывать изволишь.

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

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

Просто ты ж сам вначале создал вид, что тебе это якобы интересно, ввел в заблуждение, получается.
А теперь "красиво соскочить" не можешь, продолжаешь некрасиво суетиться, лепетать несвязное "а вы видели КАКИЕ там списки???!!!".

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

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

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

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

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

Сейчас ты тупо RIP как коллега.
Я и так тебе мильон скидок делал все эти долгие годы по понятной причине, хотя как личность ты не заслуживаешь, бо свои комплексы так и не одолел, позволяешь себе их реализацию на коллегах... но, блин, имея за спиной ВО в точных науках, столько лет обитая в IT... неужели не смог за 25 лет подтянуть примерно 2.5 года разницы программ специальностей?

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

V>>Далее я требую объяснения трижды тобой повторённого "это бред".
V>>Итак?..
S>Что "итак"? В чём вопрос-то?

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


S>Почему нельзя обойтись одной операцией Interlocked.CompareExchange? Посмотрите в код хотя бы того же MySQL. Там как бэ делается дофига чего, помимо "одной интерлокед операции".

Я и смотрел, в отличие от тебя.
Для тебя инфа по той ссылке — та самая одноразовая рыбка, которой тебя угостили.
Через единицы дней после прочтения и запаха не останется.
А учиться ловить рыбу тебе лень. ))

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

Задачей же инженера является не просто приобретение знаний в результате исследований, но непосредственное использование добытых знаний в конкретном продукте.
И знаниями, напротив, инженеры в кап.модели экономики делятся крайне неохотно, бо работодатель прямо запрещает.
Ну и, про "обособленности феномена" речи тоже обычно нет — инженер обычно работает над комплексом технических взаимодействующих проблем.

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

Мне иногда кажется в общении с тобой (с твоими посыланиями нахер DDD, с вопросами "а почему это вдруг пакет о программе знает, а программа о пакете нет?", с твоей неспособностью обсуждать никакие блокировки и вообще межпоточное взаимодействие в принципе), что с тобой надо разговаривать как с ребёнком, т.е. каждое объяснение начинать вообще с 0-ля.
Отсутствуют порой какие совсем базовые представления о том, как всё устроено и работает.

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

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

Ну понятное дело, тут сам бог велел взять тот код и начать над ним всячески измываться. ))


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

Дальше не надо было бегать.
Был вполне понятный пост:
http://www.rsdn.org/forum/flame.comp/8108421.1

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

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

Поэтому, какие в опу "таблицы", когда речь о реализации неких дисциплин диспетчеризации?
Разве некоему мьютексу требуется "знать" что там с помощью него мутуально-эксклюзивно захватывают? ))

Так и здесь.
Для режимов работы "локов" требовалось сформулировать ТЗ.
А кто там будет эти локи и как использовать — это уже другой уровень.
Я увидел очередные твои зияющие пробелы именно на этом уровне.

Мои попытки вернуть тебя на грешную землю, мол, те вещи, которые ты преподносишь как некие "знания" для юзверя СУБД, для данного уровня являются не более чем ТЗ ты тупо игноришь, т.е. опять не понимаешь, что тебе говорят и почему именно так. Информация классически не задерживается при отсутствии понимания.

В общем, предлагалось ТЗ формализировать и провести его классический анализ.
Это более чем обычный ход работ при проектировании чего угодно.

Пример RO/RW был приведён.
Ни само описание задачи RO/RW, ни его классическая реализация не были приведены по упомянутой там же причине — они общедоступны, т.е. считаем, что оно уже есть в контексте.
Т.е. можно рассматривать отдельные моменты работы предложенной к рассмотрению реализации поверх выталкивающей многозадачности.

Но у меня возникло впечатление, что я разговаривал с забором. ))

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

И зачем тебе еще одна рыба?
Через пару дней всё-равно в голове опять пусто будет.


S>В том-то и дело, что в атомарно изменяемой переменной не сохранишь весь список действующих на данный момент блокировок.

Почему ты решил, что надо хранить весь список?
Почему ты вообще пытаешься перескакивать этапы проектирования?

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


S>А его надо где-то держать и своевременно обновлять — иначе невозможно реализовать ни реентерабельность, ни конверсию локов, ни детектирование дедлоков.

Очередное ЧТД.
Для всего этого не нужны полные списки действующих "локов".
10 действующих локов какого-ти типа равны одному действующему локу этого же типа.


S>Именно поэтому так, как вы пишете, не делает в СУБД никто.

Вот, именно поэтому ты трепло, бо ты понятия не имеешь как пишут СУБД и вообще любые подобные системы.
Из пальца насасывать изволишь.

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

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

Просто ты ж сам вначале создал вид, что тебе это якобы интересно, ввел в заблуждение, получается.
А теперь "красиво соскочить" не можешь, продолжаешь некрасиво суетиться, лепетать несвязное "а вы видели КАКИЕ там списки???!!!".

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

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

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

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

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

Сейчас ты тупо RIP как коллега.
Я и так тебе мильон скидок делал все эти долгие годы по понятной причине, хотя как личность ты не заслуживаешь, бо свои комплексы так и не одолел, позволяешь себе их реализацию на коллегах... но, блин, имея за спиной ВО в точных науках, столько лет обитая в IT... неужели не смог за 25 лет подтянуть примерно 2.5 года разницы программ специальностей?