Сообщение Re[94]: MS забило на дотнет. Питону - да, сишарпу - нет? от 12.10.2021 15:10
Изменено 12.10.2021 15:22 vdimas
Re[94]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, Sinclair, Вы писали:
V>>Какое именно неадекватное решение я предлагал и почему оно неполное-то? ))
S>Неадекватное решение — реализация набора видов блокировок в СУБД через самописанный семафор
Это адекватное решение и именно так СУБД работают.
S>Неадекватное оно по вашим же словам.
Это ты придумать изволишь.
S>А неполное оно потому, что вы не показали ни API, ни реализацию такого семафора.
Было показано:
http://www.rsdn.org/forum/flame.comp/8108567.1
И там же ты оставил мой процитированный псевдокод, который позволяет добавить к семафору произвольную операцию.
V>>Речь была про то, что характеристики такого решения будут далеки от желаемых.
S>Покажите решение с характеристиками, которые близки к желаемым.
Показано.
И рассказано, что если управлять задачами самостоятельно, то от семафоров уровня ОС можно будет отказаться, по крайней мере в алгоритмах управления задачами, оставив системные семафоры только на случай, когда рабочим потокам нечего делать, чтобы иметь возможность их пробуждать (это я уже повторяюсь, бо ты невнимателен).
V>>А ты, насколько я заметил, вместо рассуждений о соотвествии встроенных ср-в ОС задачам обыгрывания нетривиальных иерархий блокировок, рассуждаешь "там всё сложно" (С).
S>Эмм, меня вообще не очень интересует соответствие встроенных в ОС средств. Интересует совершенно банальный вопрос: как будет выглядеть код выполнения запроса.
Как код реализации СУБД? ))
Ты опять задаёшь вопросы не по существу, в рамках обсуждений форума мы можем рассмотреть лишь отдельные моменты, но ты и их понять и продвинуться на шажок дальше пока не в состоянии.
S>Можно показать это на lock-free, можно на примитивах ОС, можно на какой-то комбинации. Делов-то.
Это уже.
S>Вы утверждали, что вам хватит одной интерлокед-операции для скана таблицы.
Это ты опять невнимателен.
S>Мне это утверждение кажется очевидной чушью, но я могу заблуждаться.
Ну так и перепроверил бы себя, что именно утверждалось.
А то мне на каждый абзац здесь руку-лицо ставить надо.
S>Поэтому мне хочется увидеть примерный код того, как это чудо будет реализовано. А вы вместо того, чтобы показать своё решение, растекаетесь мыслью по древу, пытаясь меня запугать очередями, СМО, и прочими не относящимися к задаче темами.
Ну и зачем так подставляться под пеняние на феномен блаба? ))
Тебе показали суть — это переключение дисциплины обслуживания ресурса с "много" на "один".
В кач-ве примера взят алгоритм блокировки RO-RW.
Чтобы осмысленно возражать, тебе сначала придётся показать, что этот алгоритм не отвечает задаче переключения дисциплины обслуживания ресурса.
И что-то мне подсказывает, что как только ты попытаешься это показать, т.е. включишь моск, многие вопросы отпадут сами собой.
S>Целью является обеспечение ACID.
Опять какой-то бред несёшь, просто не охота засорять пост десятками смайликов рука-лицо.
Заведомый ACID можно обеспечить исключительно и только одним глобальным мьютексом, через сериализацию доступа.
Требуется, наоборот, обеспечить уровни изоляции худшие, чем сериализованный, с целью увеличения уровня конкурентности системы.
S>Я не вижу хорошего способа его обеспечить без блокировок.
И я не вижу.
Это если ты верно используешь термин "блокировка" в IT, где этот термин подразумевает исключительное владение ресурсом.
Вот я ХЗ что уже думать — или ты не знал значение термина "блокировка" и вводишь оппонента в заблуждение, неточно выражая свои мысли, или ты не понимаешь даже азов, что в СУБД, наоборот, делаются некие допущения, ухудшающие ACID, что приводит как к несогласованности, так и к отказам/конфликтам (иногда повторным запускам запросов/сканов и т.д. и т.п.)
В общем, прежде чем спрашивать, неплохо бы хотя бы для себя сформулировать задачу.
И я пока не вижу, чтобы ты прошёл этот этап.
Я пока занимаюсь ликбезом и корректировкой твоих нон-стоп неточностей, в попытках понять, что именно тебе непонятно — где у тебя неточности владения терминами/формулировками, а где банальное непонимание.
Давай, плиз, выражайся яснее и читай ответы внимательней.
V>>Какое именно неадекватное решение я предлагал и почему оно неполное-то? ))
S>Неадекватное решение — реализация набора видов блокировок в СУБД через самописанный семафор
Это адекватное решение и именно так СУБД работают.
S>Неадекватное оно по вашим же словам.
Это ты придумать изволишь.
S>А неполное оно потому, что вы не показали ни API, ни реализацию такого семафора.
Было показано:
http://www.rsdn.org/forum/flame.comp/8108567.1
И там же ты оставил мой процитированный псевдокод, который позволяет добавить к семафору произвольную операцию.
V>>Речь была про то, что характеристики такого решения будут далеки от желаемых.
S>Покажите решение с характеристиками, которые близки к желаемым.
Показано.
И рассказано, что если управлять задачами самостоятельно, то от семафоров уровня ОС можно будет отказаться, по крайней мере в алгоритмах управления задачами, оставив системные семафоры только на случай, когда рабочим потокам нечего делать, чтобы иметь возможность их пробуждать (это я уже повторяюсь, бо ты невнимателен).
V>>А ты, насколько я заметил, вместо рассуждений о соотвествии встроенных ср-в ОС задачам обыгрывания нетривиальных иерархий блокировок, рассуждаешь "там всё сложно" (С).
S>Эмм, меня вообще не очень интересует соответствие встроенных в ОС средств. Интересует совершенно банальный вопрос: как будет выглядеть код выполнения запроса.
Как код реализации СУБД? ))
Ты опять задаёшь вопросы не по существу, в рамках обсуждений форума мы можем рассмотреть лишь отдельные моменты, но ты и их понять и продвинуться на шажок дальше пока не в состоянии.
S>Можно показать это на lock-free, можно на примитивах ОС, можно на какой-то комбинации. Делов-то.
Это уже.
S>Вы утверждали, что вам хватит одной интерлокед-операции для скана таблицы.
Это ты опять невнимателен.
S>Мне это утверждение кажется очевидной чушью, но я могу заблуждаться.
Ну так и перепроверил бы себя, что именно утверждалось.
А то мне на каждый абзац здесь руку-лицо ставить надо.
S>Поэтому мне хочется увидеть примерный код того, как это чудо будет реализовано. А вы вместо того, чтобы показать своё решение, растекаетесь мыслью по древу, пытаясь меня запугать очередями, СМО, и прочими не относящимися к задаче темами.
Ну и зачем так подставляться под пеняние на феномен блаба? ))
Тебе показали суть — это переключение дисциплины обслуживания ресурса с "много" на "один".
В кач-ве примера взят алгоритм блокировки RO-RW.
Чтобы осмысленно возражать, тебе сначала придётся показать, что этот алгоритм не отвечает задаче переключения дисциплины обслуживания ресурса.
И что-то мне подсказывает, что как только ты попытаешься это показать, т.е. включишь моск, многие вопросы отпадут сами собой.
S>Целью является обеспечение ACID.
Опять какой-то бред несёшь, просто не охота засорять пост десятками смайликов рука-лицо.
Заведомый ACID можно обеспечить исключительно и только одним глобальным мьютексом, через сериализацию доступа.
Требуется, наоборот, обеспечить уровни изоляции худшие, чем сериализованный, с целью увеличения уровня конкурентности системы.
S>Я не вижу хорошего способа его обеспечить без блокировок.
И я не вижу.
Это если ты верно используешь термин "блокировка" в IT, где этот термин подразумевает исключительное владение ресурсом.
Вот я ХЗ что уже думать — или ты не знал значение термина "блокировка" и вводишь оппонента в заблуждение, неточно выражая свои мысли, или ты не понимаешь даже азов, что в СУБД, наоборот, делаются некие допущения, ухудшающие ACID, что приводит как к несогласованности, так и к отказам/конфликтам (иногда повторным запускам запросов/сканов и т.д. и т.п.)
В общем, прежде чем спрашивать, неплохо бы хотя бы для себя сформулировать задачу.
И я пока не вижу, чтобы ты прошёл этот этап.
Я пока занимаюсь ликбезом и корректировкой твоих нон-стоп неточностей, в попытках понять, что именно тебе непонятно — где у тебя неточности владения терминами/формулировками, а где банальное непонимание.
Давай, плиз, выражайся яснее и читай ответы внимательней.
Re[94]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, Sinclair, Вы писали:
V>>Какое именно неадекватное решение я предлагал и почему оно неполное-то? ))
S>Неадекватное решение — реализация набора видов блокировок в СУБД через самописанный семафор
Это адекватное решение и именно так СУБД работают.
S>Неадекватное оно по вашим же словам.
Это ты придумать изволишь.
S>А неполное оно потому, что вы не показали ни API, ни реализацию такого семафора.
Было показано:
http://www.rsdn.org/forum/flame.comp/8108567.1
И там же ты оставил мой процитированный псевдокод, который позволяет добавить к семафору произвольную операцию.
V>>Речь была про то, что характеристики такого решения будут далеки от желаемых.
S>Покажите решение с характеристиками, которые близки к желаемым.
Показано.
И рассказано, что если управлять задачами самостоятельно, то от семафоров уровня ОС можно будет отказаться, по крайней мере в алгоритмах управления задачами, оставив системные семафоры только на случай, когда рабочим потокам нечего делать, чтобы иметь возможность их пробуждать (это я уже повторяюсь, бо ты невнимателен).
V>>А ты, насколько я заметил, вместо рассуждений о соотвествии встроенных ср-в ОС задачам обыгрывания нетривиальных иерархий блокировок, рассуждаешь "там всё сложно" (С).
S>Эмм, меня вообще не очень интересует соответствие встроенных в ОС средств. Интересует совершенно банальный вопрос: как будет выглядеть код выполнения запроса.
Как код реализации СУБД? ))
Ты опять задаёшь вопросы не по существу, в рамках обсуждений форума мы можем рассмотреть лишь отдельные моменты, но ты и их понять и продвинуться на шажок дальше пока не в состоянии.
S>Можно показать это на lock-free, можно на примитивах ОС, можно на какой-то комбинации. Делов-то.
Это уже.
S>Вы утверждали, что вам хватит одной интерлокед-операции для скана таблицы.
Это ты опять невнимателен.
S>Мне это утверждение кажется очевидной чушью, но я могу заблуждаться.
Ну так и перепроверил бы себя, что именно утверждалось.
А то мне на каждый абзац здесь руку-лицо ставить надо.
S>Поэтому мне хочется увидеть примерный код того, как это чудо будет реализовано. А вы вместо того, чтобы показать своё решение, растекаетесь мыслью по древу, пытаясь меня запугать очередями, СМО, и прочими не относящимися к задаче темами.
Ну и зачем так подставляться под пеняние на феномен блаба? ))
Тебе показали суть — это переключение дисциплины обслуживания ресурса с "много" на "один".
В кач-ве примера взят алгоритм блокировки RO-RW.
Алгоритм и суть происходящего в проблематике RO-RW предполагается известным всем сторонам (в любом случае, независимой инфы про эту проблематику хватает).
Чтобы осмысленно возражать, тебе сначала придётся показать, что этот алгоритм не отвечает задаче переключения дисциплины обслуживания ресурса.
И что-то мне подсказывает, что как только ты попытаешься это показать, т.е. включишь моск, многие вопросы отпадут сами собой.
S>Целью является обеспечение ACID.
Опять какой-то бред несёшь, просто не охота засорять пост десятками смайликов рука-лицо.
Заведомый ACID можно обеспечить исключительно и только одним глобальным мьютексом, через сериализацию доступа.
Требуется, наоборот, обеспечить уровни изоляции худшие, чем сериализованный, с целью увеличения уровня конкурентности системы.
S>Я не вижу хорошего способа его обеспечить без блокировок.
И я не вижу.
Это если ты верно используешь термин "блокировка" в IT, где этот термин подразумевает исключительное владение ресурсом.
Вот я ХЗ что уже думать — или ты не знал значение термина "блокировка" и вводишь оппонента в заблуждение, неточно выражая свои мысли, или ты не понимаешь даже азов, что в СУБД, наоборот, делаются некие допущения, ухудшающие ACID, что приводит как к несогласованности, так и к отказам/конфликтам (иногда повторным запускам запросов/сканов и т.д. и т.п.)
В общем, прежде чем спрашивать, неплохо бы хотя бы для себя сформулировать задачу.
И я пока не вижу, чтобы ты прошёл этот этап.
Я пока занимаюсь ликбезом и корректировкой твоих нон-стоп неточностей, в попытках понять, что именно тебе непонятно — где у тебя неточности владения терминами/формулировками, а где банальное непонимание.
Давай, плиз, выражайся яснее и читай ответы внимательней.
V>>Какое именно неадекватное решение я предлагал и почему оно неполное-то? ))
S>Неадекватное решение — реализация набора видов блокировок в СУБД через самописанный семафор
Это адекватное решение и именно так СУБД работают.
S>Неадекватное оно по вашим же словам.
Это ты придумать изволишь.
S>А неполное оно потому, что вы не показали ни API, ни реализацию такого семафора.
Было показано:
http://www.rsdn.org/forum/flame.comp/8108567.1
И там же ты оставил мой процитированный псевдокод, который позволяет добавить к семафору произвольную операцию.
V>>Речь была про то, что характеристики такого решения будут далеки от желаемых.
S>Покажите решение с характеристиками, которые близки к желаемым.
Показано.
И рассказано, что если управлять задачами самостоятельно, то от семафоров уровня ОС можно будет отказаться, по крайней мере в алгоритмах управления задачами, оставив системные семафоры только на случай, когда рабочим потокам нечего делать, чтобы иметь возможность их пробуждать (это я уже повторяюсь, бо ты невнимателен).
V>>А ты, насколько я заметил, вместо рассуждений о соотвествии встроенных ср-в ОС задачам обыгрывания нетривиальных иерархий блокировок, рассуждаешь "там всё сложно" (С).
S>Эмм, меня вообще не очень интересует соответствие встроенных в ОС средств. Интересует совершенно банальный вопрос: как будет выглядеть код выполнения запроса.
Как код реализации СУБД? ))
Ты опять задаёшь вопросы не по существу, в рамках обсуждений форума мы можем рассмотреть лишь отдельные моменты, но ты и их понять и продвинуться на шажок дальше пока не в состоянии.
S>Можно показать это на lock-free, можно на примитивах ОС, можно на какой-то комбинации. Делов-то.
Это уже.
S>Вы утверждали, что вам хватит одной интерлокед-операции для скана таблицы.
Это ты опять невнимателен.
S>Мне это утверждение кажется очевидной чушью, но я могу заблуждаться.
Ну так и перепроверил бы себя, что именно утверждалось.
А то мне на каждый абзац здесь руку-лицо ставить надо.
S>Поэтому мне хочется увидеть примерный код того, как это чудо будет реализовано. А вы вместо того, чтобы показать своё решение, растекаетесь мыслью по древу, пытаясь меня запугать очередями, СМО, и прочими не относящимися к задаче темами.
Ну и зачем так подставляться под пеняние на феномен блаба? ))
Тебе показали суть — это переключение дисциплины обслуживания ресурса с "много" на "один".
В кач-ве примера взят алгоритм блокировки RO-RW.
Алгоритм и суть происходящего в проблематике RO-RW предполагается известным всем сторонам (в любом случае, независимой инфы про эту проблематику хватает).
Чтобы осмысленно возражать, тебе сначала придётся показать, что этот алгоритм не отвечает задаче переключения дисциплины обслуживания ресурса.
И что-то мне подсказывает, что как только ты попытаешься это показать, т.е. включишь моск, многие вопросы отпадут сами собой.
S>Целью является обеспечение ACID.
Опять какой-то бред несёшь, просто не охота засорять пост десятками смайликов рука-лицо.
Заведомый ACID можно обеспечить исключительно и только одним глобальным мьютексом, через сериализацию доступа.
Требуется, наоборот, обеспечить уровни изоляции худшие, чем сериализованный, с целью увеличения уровня конкурентности системы.
S>Я не вижу хорошего способа его обеспечить без блокировок.
И я не вижу.
Это если ты верно используешь термин "блокировка" в IT, где этот термин подразумевает исключительное владение ресурсом.
Вот я ХЗ что уже думать — или ты не знал значение термина "блокировка" и вводишь оппонента в заблуждение, неточно выражая свои мысли, или ты не понимаешь даже азов, что в СУБД, наоборот, делаются некие допущения, ухудшающие ACID, что приводит как к несогласованности, так и к отказам/конфликтам (иногда повторным запускам запросов/сканов и т.д. и т.п.)
В общем, прежде чем спрашивать, неплохо бы хотя бы для себя сформулировать задачу.
И я пока не вижу, чтобы ты прошёл этот этап.
Я пока занимаюсь ликбезом и корректировкой твоих нон-стоп неточностей, в попытках понять, что именно тебе непонятно — где у тебя неточности владения терминами/формулировками, а где банальное непонимание.
Давай, плиз, выражайся яснее и читай ответы внимательней.