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

V>>Прежде чем проcить решение задачи, задачу надо сформулировать.
S>Ок, вернёмся на сто шагов назад.
S>

S>>Даже в отсутствие конфликтов блокировки отжирают время.
S>В отсутствии конфликтов — одна интерлокед-операция на таблицу для скана таблицы.
S>Считай, бесплатно.

S>Видите, с чего всё начинается?

Ну так и с чего? Смелее!
Что ты как брат нибэнимэда? ))

Третий раз пытаюсь тебя расколоть, занадоел, реально.
Прямой речью спрашиваю — как ты понимаешь фразу "одна интерлокед-операция"?
С учётом двухкратных отсылок к циклу обновления, плюс первый раз когда его привели (и по наивности посчитали, что достаточно).

Итак, ты прочитал это как "операций интерлокед-характера требуется одна штука", или как "операция вообще одна, которая интерлокед и есть".

Кароч, Синклер, хватит, сорри за мой французский, сцать!
Говори уже прямой речью.


S>Я вам пытаюсь объяснить простую вещь: себестоимость поддержки изоляции транзакций на фоне затрат на интерпретацию планов запросов.

Тпруу, ничего такого ты не пытался никому объяснить, сейчас пытаешься подменить тезис в очередной раз.

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

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


S>Вы — не вьезжаете, и начинаете писать чушь.

Так не въезжаю во что именно?

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

Но как быть с твоим гаденьким способом сливаться на бабский (в плохом смысле этого слова) манер оставления за собой уже абы какого последнего слова: "и всё-равно вы ничего не понимаете"? На дуэль бабомужика вызывать или как? ))


S>В следующем посте я уточняю область моей обеспокоенности:
S>

S>Вопрос — в том, как обеспечить быстродействие в реальных задачах, особенно когда планировщик заранее не знает, сколько строк попадёт под предикат.

Бгг...
Ситуация:
— Как работает двигатель?
— ОК, начнём с основных составляющих, вот поршни, вот цилиндры, ...
— Стойте, стойте! Как РАБОТАЕТ двигатель?
— (Ммм, наверно отличник какой-то) ОК — вот простейший адиабатический процесс, предлагаю разобрать сначала его, потому что реальные процессы в двигателе описываются более сложными моделями, чем адиаба...
— Я вас спросил КАК. РАБОТАЕТ. ДВИГАТЕЛЬ??? А не про поршни, и эти ваши дурацкие про... про... проссесцы, или как их там, даже запоминать эту чушь не хочу!!!


S>Вот она, эта задача.

Создай под эту задачу другой топик и обсуждай.
И наберись мужества не пытаться заниматься подменой тезисов в том топике, а то тебя колбасит нипадецки.

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


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

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

Именно поэтому меня улыбает, когда многие упоминавшиеся тобой вещи ты пытался приписать сугубо СУБД.
Это общая практика проектирования подобных систем, где большое кол-во структурированных данных активно обновляется достаточно большим хаотичным трафиком.


S>Механизмы обеспечения A, I, и D в ACID хорошо известны и изложены в той самой литературе, которую вы избегаете читать (но регулярно пытаетесь отправить её читать меня).

Ни в коем случае не к этой литературе, бог с тобой.
Я тебя пытаюсь отправить к литературе для разработчика.
А ты капризничаешь "нихачу".

Всё что написано в той литературе, куда ты пытаешься отслать, грамотному специалисту можно изложить на одной-двух страницах, даже если он раньше никогда не слышал.
Если слышал — просто перечислить в одной-двух строках.

Это как взять Капитал Маркса — суть произведения можно изложить ровно в 3-х абзацах:
— прошлое и настоящее (на тот момент) капитализма;
— выведенная закономерность превращения капитализма в империализм;
— найденная формула "угнетения народных масс" — т.н. добавочная стоимость.

Но изложение построено по принципу наворачивания кругов об одном и том же, от простого к "сложному", для целевой неподготовленной публики.


S>Вопрос — в себестоимости этих механизмов.

Вот, про себестоимость — это ко мне.
Хотя ты несколько раз повторил, что это тебе не интересно.

Но вопрос в том числе в ней, родной, ес-но.
Бо когда у нас "себестоимость" изменяется в 50 и более раз только за счёт изменения механизмов и самих принципов "синхронизации", то я в этих устрицах знаю толк.


V>>Начал-то я немного с другого, с того, что "прикладные виды блокировок" в отсутствии понимания, что они из себя представляют унутре, лишь засоряют твой моск.
V>>Отсюда и понеслась. ))
S>А то. Невооружённым взглядом видно, что отсутствие знаний о "прикладных видах блокировок" мешает вам осмысленно обсуждать устройство СУБД

Ой дичь.
Такие вещи идут как постановка задачи, а не "добываемые с трудом знания".

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

Просто ты не видишь, что ле, изначальной цели этого обсуждения.
А она проста: угостить одной рыбёшкой и научить ловить рыбу — разные вещи.


S>Так как вы не очень представляете требования к менеджеру блокировок в СУБД, вы начинаете изобретать нерабочие велосипеды.

Какие мы громкие опять, не успел обсохнуть...
Не докажешь "нерабочесть" — пойдёшь за пустомелю.


V>>Верно, тебе демонстровали влияние характера поступающих заявок на ход решения, т.е. на разрабатываемые алгоритмы реализации такой СМО.
S>Ну и зачем вся эта феерия?

Иначе не понять, т.е. даже не суметь сформулировать задачу.
Так и будешь барахтаться на уровне "продвинутого юзверя".

Есть такая присказка — молодец посредь овец, и далее по тексту.

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

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

И препод принял у тебя тот алгоритм, не потому что алгоритм был хорош, а потому что он не мог требовать с тебя того, что вам не преподавали.
У вас проверяли навыки простейшего программирования моделей, судя по всему.
Неадекватность самой модели не учитывалась. ))

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

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

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

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


S>Мы ни на йоту не приблизились к пониманию того, что реально происходит в СУБД при захвате блокировки.

Потому что сабботаж?
Потому что ты поставил себе цель оставить "это" за пределами понимания как своего, так и потенциальных читателей?
Чтобы не вышло опять смешно как с той трубой?

Я это вижу как банальную трусость.


S>Ну так а толку всё это озвучивать, когда эти факты никакого влияния на ход вашего решения не оказывают? Ваш семафор не умеет делать банальную конверсию read lock в write lock.

Код целиком не привели? (опять ржу че-та)

На это тебе уже ответили — ф-ия read из CRT тоже не умеет читать файл построчно, но с помощью этого read построчно прочитать файл элементарно.
С помощью уже показанного тебе кода нарисовать RO-RW замок — как два пальца об асфальт.
Т.е. простейшую СМО с двумя состояниями.

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


S>Голодание писателей — это десятая по важности проблема после базовой функциональности

Мде? ))

Без учёта эффекта голодания писателей, при увеличении трафика читателей писатели вообще не смогут достучаться до ресурса ни-ко-гда.
Т.е., чем ближе к 0-лю вероятность нулевой длины очереди читателей (в любой конкретный момент времени), тем ближе к бесконечности очередь писателей.

Т.е., не обязательно писать конкретный код, расписывая до компилябельности и обыгрывания всех граничных случаев, по дороге борясь с конкретным ЯП.
Иногда достаточно на принципиальном уровне рассмотреть происходящее в том или ином алгоритме.

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

С тойбо делились тем наблюдением, что в любой реализации требуемого "замка" могут быть некие заведомо "встроенные" в данную реализацию проблемы.
Тебе показали (А) — что проблемы в хаотичном трафике бывают и (Б) что обнаружение проблем еще на стадии анализа/моделирования и их решение является неотъемлимой частью разработки.


S>без которой о реализации изоляции транзакций в СУБД и заикаться нечего.

Для особо одарённых еще раз — уровни изоляции не равны блокировкам.

Тебе уже дважды объясняли, как изоляция страницы для читателей может быть выполнена только через shared-блокировку её по чтению, через механизм COW.
Через это работают в т.ч. твои repetable read.

До смешного, тебе рассказывают об этом механизме уже несколько постов, а ты потом преподносишь repetable read как откровение.
Ситуация забавна — у тебя отсутствует сопоставление между названиями "блокировок" и реально происходящего в базе.


S>Для интересу, можете ознакомиться с тем, что происходит в настоящих СУБД на примере вот этой статьи.

Ознакомился, рассмотрена реализация специфичной хеш-таблицы для многопоточности, и?
Не так давно я тебе тоже описывал способы построения специфичных для многопоточности хеш-таблиц, И? (С большой "И")

Что сказать-то хотел?
Что тебе обязаны были такого объема статью сходу накатать?
Не убедившись, что это действительно нужно?

Тебе говорили прямой речью несколько раз — от тебя требуется проявить (А) интерес и (Б) способность к восприятию информации.
Иначе нахрена твоему собеседнику против ветра мочиться-то? ))


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

Именно так.
"Фундаментальные" вещи, они именно такие.
Это те, через комбинаторику которых остальное "выводится".


S>Кроме псевдокода можно посмотреть на то, какие факторы влияют на быстродействие механизма блокировок. В частности, как раз те самые операции над списками блокировок

Только не списками, а некоей иерархией, в статье "LOCKING WITH LESS LATCHING".
Т.е. модель-то простая — введен однонаправленный граф отношений блокировок.
Я предлагал просто пронумеровать, помнишь?

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


S>о которых у вас вообще не упомянуто

Да упомянуто сто раз и по-разному.

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


S>и ровно потому, что вы понятия не имеете, что и зачем вынуждены делать реальные СУБД.

Или по другой причине — потому что ты упоротый сноб, которому "имидж" важнее знаний.

Конкретно в этом обсуждении совсем уж неприкрыто выглядит так, что тебя оскорбляет сама мысль о том, что "кто-то в интернете что-то знает лучше тебя".
Ваще зашквар...


S>На фоне вот этих приседаний ваша экономия легковесным семафором — спички.

Ага, раз в 50 разница в эффективности всей системы, а так-то мелочи.
Ты статью-то по своей ссылке читал?
В код вникал?
Похоже ты не обратил внимание, что в исходном коде MySQL "объект-замок" (create_lock) — это не "семафор" и никакой другой встроенный примитив синхронизации.

И что проблема в том коде конкретно вот здесь:
mutex_enter(lock_table->mutex)

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

И беседа забавная именно по этой причине у нас выходит: "ты куда, в баню? — да нет, в баню".

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


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

От тебя зависело.
Проявил бы желание разобраться — разобрали бы.
Встал в позу — равно или поздно был бы всё-равно послан.
Я просто даю обычно некоторое время собеседнику пройти от стадии отрицания до стадии понимания-угомонения.

У тебя, кстате, иногда получалось.
Наверно, на этот раз я слишком большой кусок тебе предложил. ))


S>У вас же есть два режима общения. Один — это кривляния.

Ну да, это же такое было моё кривляние — объяснение проблематики RO-RW и объяснение — зачем вообще вся эта проблематика озвучивается, да еще в кач-ве демонстрации характера задач, которые приходится решать.

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

Теперь ты просто удобный манекен для демонстрации того, каким быть нельзя.


S>А второй режим — когда вы внезапно перестаёте выделываться и пишете по делу.

Та я ваще пофигист.
Сказано же — от тебя зависит.
Показываешь себя гадливо-обидчивым на какую-то феерически-ничтожную с моей колокольни весч — не обессудь.


V>>Если человек не сможет через read и небольшой буфер сам, без подсказок, написать алгоритм построчного чтения файла, ему лучше сходу слиться.
S>Видите ли, чтобы претендовать на позицию учителя, нужно быть готовым самому "сесть за руль".

Во-во, "претендовать". ))
Хулиганы зрения хлеба лишают?
Да понятно это стало уже с 3-го твоего поста здесь...

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


S>Но вот за вами такой готовности незаметно — ни в этом топике, ни в каких других. У вас всегда наготове критика, переваливание ответственности на других, и смелые заявления "я бы сделал лучше".

Нормальные заявления в подходящих для этого местах.
Я же не просто говорил "там можно было сделать лучше", я озвучил — как именно.

Да и ты своим "умозрительным кодом" не возражал, а подтверждал, помнится, что аж в какой-то момент натурально надоел.
Еще и тем, что строил ответы якобы в виде возражений, лишь подтверждая "умозрительностью" мою основную мысль о де-факто состоянии мн-ва дотнетных дров к СУБД.


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

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

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

Потому что похожие задачи сплошь и рядом возникают не только в СУБД, ес-но.

У СУБД своя специфика, понятно, свои наработки, показавшие себя лучше всего за все эти 30 лет их успеха, что-то показавшее себя неважно уже умерло и т.д.
Т.е., в других задачах, вполне вероятно (и оно так и есть) может быть другой список и блокировок, и отношений м/у ними — это часто еще зависит от характера задач и данных.

В этом смысле блокировки в БД туповатенькие, конечно, т.к. про характер задач и данных не в курсе, поэтому релизуют самые общие и часто не самые эффективные алгоритмы, будучи рассмотренными для конкретных сценариев.

Но общий принцип решения "задач о блокировках" — он, считай один.
Других наработок как теоретических, так и в плане иммитационного моделирования, чем СМО на сегодня банально нет.

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

Это перекликается с твоим столь же ожесточённым отрицанием DDD — в разработке сложных современных ПО-систем выжил только этот подход, другие умерли за несостоятельностью.
А этот выжил по простой прчине — является проекцией системного подхода на случай, когда речь сугубо о ПО (в общем случае на наших специальностях натаскивают на разработку аппаратно-программных комплексов, т.е. разработка только ПО — это несколько ограничение "потолка" роста, и это местами немного угнетает... хотя, нехило компенсируется зарплатой... но такова специфика экс-СССР айти).

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


S>То, что вы делаете — это совершенно прозрачная попытка скрыть свои затруднения и непонимание за менторским тоном.

У меня пока одно затруднение — ученик отказывается учиться.
И не в том ученик уже возрасте, когда есть возможность надавить/заставить, через родителей, просто поругать и т.д. ))


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

Ничего не было скипнуто, ля врать-то. ))
Я отвечаю на всё подряд в каждом посте, пока не надоедает.

Обычно набирается твоих 3-5 залётов — и я отправляю тебя на новый круг, бо этот считается непройденным.

Но и это не всё...
Вот это твоё постоянное замыливание, вся эта мышиная возня какая-то мелочная-дурацкая...

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

И всё больше уверен, что это тупо отлынивание от изучения предмета, банально лень ума.
Хочешь болтать тупо ни о чём? ))

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


S>Мне вот совершенно не стыдно признаться в том, что я не очень хорошо разбираюсь в многопоточном программировании, и, скажем, не могу (в отличие от многих коллег на форуме) сходу ткнуть пальцем в код синхронизации со словами "у вас тут гонка".

А как ты себе вообще представляешь "уметь разбираться в многопоточности"?
Там, вроде, на пальцы одной руки понятий (атомарно/неатомарно, локально/нелокально).
Остальное — банальная внимательность.


S>Зато я хорошо разбираюсь в том, как работают различные СУБД, от игрушечных до промышленных.

И как в этом можно разбираться, не разбираясь в многопоточности?

Путаешь с "ознакомиться с руководством пользователя".

Это как с языком программирования — если сможешь написать для некоего ЯП компилятор-интерпретатор — ты понял этот язык.
Не сможешь — еще не понял.

С СУБД аналогично.
Сможешь их писать, от парсера КС-грамматики SQL, через преобразование/факторизацию уравнений РА (с целью приведения к шагам твоего "плана запроса") и до исполнения этого плана в конкурентной среде — тогда ты понимаешь, что в СУБД происходит. Нет — нет. Тогда ты просто "администратор БД".


S>И разбираюсь я в этом не для того, чтобы унижать людей на форумах — в отличие от вас, мне не стрёмно объяснить кому угодно непонятные места. Я поэтому и преподавать пошёл.

Ты преподаешь ведущим специалистам с 30-тилетним стажем?
Сорри, но не верю.

А может ты лекции читаешь студентам, т.е. минимум доцент?
А на какую темы был диссер, почему не похвастался еще?

Или ты там лаборант/практик?
А мне тут втирать опять изволишь?

Тут же почти все твои собеседники имеют ВО, прекрасно в курсе, что лаборантами/практиками работают даже зеленые аспиранты, которые вот только сами ВУЗ закончили.
Ну и я в ВУЗ-е остался сначала, но в первый же год был вынужден уйти из-за ничтожной ЗП, И? (большое "И")
А корешь остался, правда, ненадолго.

Это таков был "последний аргумент?"

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

В общем, если ты этим прямо заявляешь, что ученик в тебе умер — так можно уже хоронить. ))

(фуф, пипец)

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

V>>Прежде чем проcить решение задачи, задачу надо сформулировать.
S>Ок, вернёмся на сто шагов назад.
S>

S>>Даже в отсутствие конфликтов блокировки отжирают время.
S>В отсутствии конфликтов — одна интерлокед-операция на таблицу для скана таблицы.
S>Считай, бесплатно.

S>Видите, с чего всё начинается?

Ну так и с чего? Смелее!
Что ты как брат нибэнимэда? ))

Третий раз пытаюсь тебя расколоть, занадоел, реально.
Прямой речью спрашиваю — как ты понимаешь фразу "одна интерлокед-операция"?
С учётом двухкратных отсылок к циклу обновления, плюс первый раз когда его привели (и по наивности посчитали, что достаточно).

Итак, ты прочитал это как "операций интерлокед-характера требуется одна штука", или как "операция вообще одна, которая интерлокед и есть".

Кароч, Синклер, хватит, сорри за мой французский, сцать!
Говори уже прямой речью.


S>Я вам пытаюсь объяснить простую вещь: себестоимость поддержки изоляции транзакций на фоне затрат на интерпретацию планов запросов.

Тпруу, ничего такого ты не пытался никому объяснить, сейчас пытаешься подменить тезис в очередной раз.

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

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


S>Вы — не вьезжаете, и начинаете писать чушь.

Так не въезжаю во что именно?

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

Но как быть с твоим гаденьким способом сливаться на бабский (в плохом смысле этого слова) манер оставления за собой уже абы какого последнего слова: "и всё-равно вы ничего не понимаете"? На дуэль бабомужика вызывать или как? ))


S>В следующем посте я уточняю область моей обеспокоенности:
S>

S>Вопрос — в том, как обеспечить быстродействие в реальных задачах, особенно когда планировщик заранее не знает, сколько строк попадёт под предикат.

Бгг...
Ситуация:
— Как работает двигатель?
— ОК, начнём с основных составляющих, вот поршни, вот цилиндры, ...
— Стойте, стойте! Как РАБОТАЕТ двигатель?
— (Ммм, наверно отличник какой-то) ОК — вот простейший адиабатический процесс, предлагаю разобрать сначала его, потому что реальные процессы в двигателе описываются более сложными моделями, чем адиаба...
— Я вас спросил КАК. РАБОТАЕТ. ДВИГАТЕЛЬ??? А не про поршни, и эти ваши дурацкие про... про... проссесцы, или как их там, даже запоминать эту чушь не хочу!!!


S>Вот она, эта задача.

Создай под эту задачу другой топик и обсуждай.
И наберись мужества не пытаться заниматься подменой тезисов в том топике, а то тебя колбасит нипадецки.

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


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

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

Именно поэтому меня улыбает, когда многие упоминавшиеся тобой вещи ты пытался приписать сугубо СУБД.
Это общая практика проектирования подобных систем, где большое кол-во структурированных данных активно обновляется достаточно большим хаотичным трафиком.


S>Механизмы обеспечения A, I, и D в ACID хорошо известны и изложены в той самой литературе, которую вы избегаете читать (но регулярно пытаетесь отправить её читать меня).

Ни в коем случае не к этой литературе, бог с тобой.
Я тебя пытаюсь отправить к литературе для разработчика.
А ты капризничаешь "нихачу".

Всё что написано в той литературе, куда ты пытаешься отслать, грамотному специалисту можно изложить на одной-двух страницах, даже если он раньше никогда не слышал.
Если слышал — просто перечислить в одной-двух строках.

Это как взять Капитал Маркса — суть произведения можно изложить ровно в 3-х абзацах:
— прошлое и настоящее (на тот момент) капитализма;
— выведенная закономерность превращения капитализма в империализм;
— найденная формула "угнетения народных масс" — т.н. добавочная стоимость.

Но изложение построено по принципу наворачивания кругов об одном и том же, от простого к "сложному", для целевой неподготовленной публики.


S>Вопрос — в себестоимости этих механизмов.

Вот, про себестоимость — это ко мне.
Хотя ты несколько раз повторил, что это тебе не интересно.

Но вопрос в том числе в ней, родной, ес-но.
Бо когда у нас "себестоимость" изменяется в 50 и более раз только за счёт изменения механизмов и самих принципов "синхронизации", то я в этих устрицах знаю толк.


V>>Начал-то я немного с другого, с того, что "прикладные виды блокировок" в отсутствии понимания, что они из себя представляют унутре, лишь засоряют твой моск.
V>>Отсюда и понеслась. ))
S>А то. Невооружённым взглядом видно, что отсутствие знаний о "прикладных видах блокировок" мешает вам осмысленно обсуждать устройство СУБД

Ой дичь.
Такие вещи идут как постановка задачи, а не "добываемые с трудом знания".

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

Просто ты не видишь, что ле, изначальной цели этого обсуждения.
А она проста: угостить одной рыбёшкой и научить ловить рыбу — разные вещи.


S>Так как вы не очень представляете требования к менеджеру блокировок в СУБД, вы начинаете изобретать нерабочие велосипеды.

Какие мы громкие опять, не успел обсохнуть...
Не докажешь "нерабочесть" — пойдёшь за пустомелю.


V>>Верно, тебе демонстровали влияние характера поступающих заявок на ход решения, т.е. на разрабатываемые алгоритмы реализации такой СМО.
S>Ну и зачем вся эта феерия?

Иначе не понять, т.е. даже не суметь сформулировать задачу.
Так и будешь барахтаться на уровне "продвинутого юзверя".

Есть такая присказка — молодец посредь овец, и далее по тексту.

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

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

И препод принял у тебя тот алгоритм, не потому что алгоритм был хорош, а потому что он не мог требовать с тебя того, что вам не преподавали.
У вас проверяли навыки простейшего программирования моделей, судя по всему.
Неадекватность самой модели не учитывалась. ))

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

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

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

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


S>Мы ни на йоту не приблизились к пониманию того, что реально происходит в СУБД при захвате блокировки.

Потому что сабботаж?
Потому что ты поставил себе цель оставить "это" за пределами понимания как своего, так и потенциальных читателей?
Чтобы не вышло опять смешно как с той трубой?

Я это вижу как банальную трусость.


S>Ну так а толку всё это озвучивать, когда эти факты никакого влияния на ход вашего решения не оказывают? Ваш семафор не умеет делать банальную конверсию read lock в write lock.

Код целиком не привели? (опять ржу че-та)

На это тебе уже ответили — ф-ия read из CRT тоже не умеет читать файл построчно, но с помощью этого read построчно прочитать файл элементарно.
С помощью уже показанного тебе кода нарисовать RO-RW замок — как два пальца об асфальт.
Т.е. простейшую СМО с двумя состояниями.

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


S>Голодание писателей — это десятая по важности проблема после базовой функциональности

Мде? ))

Без учёта эффекта голодания писателей, при увеличении трафика читателей писатели вообще не смогут достучаться до ресурса ни-ко-гда.
Т.е., чем ближе к 0-лю вероятность нулевой длины очереди читателей (в любой конкретный момент времени), тем ближе к бесконечности очередь писателей.

Т.е., не обязательно писать конкретный код, расписывая до компилябельности и обыгрывания всех граничных случаев, по дороге борясь с конкретным ЯП.
Иногда достаточно на принципиальном уровне рассмотреть происходящее в том или ином алгоритме.

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

С тойбо делились тем наблюдением, что в любой реализации требуемого "замка" могут быть некие заведомо "встроенные" в данную реализацию проблемы.
Тебе показали (А) — что проблемы в хаотичном трафике бывают и (Б) что обнаружение проблем еще на стадии анализа/моделирования и их решение является неотъемлимой частью разработки.


S>без которой о реализации изоляции транзакций в СУБД и заикаться нечего.

Для особо одарённых еще раз — уровни изоляции не равны блокировкам.

Тебе уже дважды объясняли, как изоляция страницы для читателей может быть выполнена только через shared-блокировку её по чтению, через механизм COW.
Через это работают в т.ч. твои repetable read.

До смешного, тебе рассказывают об этом механизме уже несколько постов, а ты потом преподносишь repetable read как откровение.
Ситуация забавна — у тебя отсутствует сопоставление между названиями "блокировок" и реально происходящего в базе.


S>Для интересу, можете ознакомиться с тем, что происходит в настоящих СУБД на примере вот этой статьи.

Ознакомился, рассмотрена реализация специфичной хеш-таблицы для многопоточности, и?
Не так давно я тебе тоже описывал способы построения специфичных для многопоточности хеш-таблиц, И? (С большой "И")

Что сказать-то хотел?
Что тебе обязаны были такого объема статью сходу накатать?
Не убедившись, что это действительно нужно?

Тебе говорили прямой речью несколько раз — от тебя требуется проявить (А) интерес и (Б) способность к восприятию информации.
Иначе нахрена твоему собеседнику против ветра мочиться-то? ))


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

Именно так.
"Фундаментальные" вещи, они именно такие.
Это те, через комбинаторику которых остальное "выводится".


S>Кроме псевдокода можно посмотреть на то, какие факторы влияют на быстродействие механизма блокировок. В частности, как раз те самые операции над списками блокировок

Только не списками, а некоей иерархией, в статье "LOCKING WITH LESS LATCHING".
Т.е. модель-то простая — введен однонаправленный граф отношений блокировок.
Я предлагал просто пронумеровать, помнишь?

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


S>о которых у вас вообще не упомянуто

Да упомянуто сто раз и по-разному.

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


S>и ровно потому, что вы понятия не имеете, что и зачем вынуждены делать реальные СУБД.

Или по другой причине — потому что ты упоротый сноб, которому "имидж" важнее знаний.

Конкретно в этом обсуждении совсем уж неприкрыто выглядит так, что тебя оскорбляет сама мысль о том, что "кто-то в интернете что-то знает лучше тебя".
Ваще зашквар...


S>На фоне вот этих приседаний ваша экономия легковесным семафором — спички.

Ага, раз в 50 разница в эффективности всей системы, а так-то мелочи.
Ты статью-то по своей ссылке читал?
В код вникал?
Похоже ты не обратил внимание, что в исходном коде MySQL "объект-замок" (create_lock) — это не "семафор" и никакой другой встроенный примитив синхронизации.

И что проблема в том коде конкретно вот здесь:
mutex_enter(lock_table->mutex)

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

И беседа забавная именно по этой причине у нас выходит: "ты куда, в баню? — да нет, в баню".

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


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

От тебя зависело.
Проявил бы желание разобраться — разобрали бы.
Встал в позу — равно или поздно был бы всё-равно послан.
Я просто даю обычно некоторое время собеседнику пройти от стадии отрицания до стадии понимания-угомонения.

У тебя, кстате, иногда получалось.
Наверно, на этот раз я слишком большой кусок тебе предложил. ))


S>У вас же есть два режима общения. Один — это кривляния.

Ну да, это же такое было моё кривляние — объяснение проблематики RO-RW и объяснение — зачем вообще вся эта проблематика озвучивается, да еще в кач-ве демонстрации характера задач, которые приходится решать.

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

Теперь ты просто удобный манекен для демонстрации того, каким быть нельзя.


S>А второй режим — когда вы внезапно перестаёте выделываться и пишете по делу.

Та я ваще пофигист.
Сказано же — от тебя зависит.
Показываешь себя гадливо-обидчивым на какую-то феерически-ничтожную с моей колокольни весч — не обессудь.


V>>Если человек не сможет через read и небольшой буфер сам, без подсказок, написать алгоритм построчного чтения файла, ему лучше сходу слиться.
S>Видите ли, чтобы претендовать на позицию учителя, нужно быть готовым самому "сесть за руль".

Во-во, "претендовать". ))
Хулиганы зрения хлеба лишают?
Да понятно это стало уже с 3-го твоего поста здесь...

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


S>Но вот за вами такой готовности незаметно — ни в этом топике, ни в каких других. У вас всегда наготове критика, переваливание ответственности на других, и смелые заявления "я бы сделал лучше".

Нормальные заявления в подходящих для этого местах.
Я же не просто говорил "там можно было сделать лучше", я озвучил — как именно.

Да и ты своим "умозрительным кодом" не возражал, а подтверждал, помнится, что аж в какой-то момент натурально надоел.
Еще и тем, что строил ответы якобы в виде возражений, лишь подтверждая "умозрительностью" мою основную мысль о де-факто состоянии мн-ва дотнетных дров к СУБД.


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

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

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

Потому что похожие задачи сплошь и рядом возникают не только в СУБД, ес-но.

У СУБД своя специфика, понятно, свои наработки, показавшие себя лучше всего за все эти 30 лет их успеха, что-то показавшее себя неважно уже умерло и т.д.
Т.е., в других задачах, вполне вероятно (и оно так и есть) может быть другой список и блокировок, и отношений м/у ними — это часто еще зависит от характера задач и данных.

В этом смысле блокировки в БД туповатенькие, конечно, т.к. про характер задач и данных не в курсе, поэтому релизуют самые общие и часто не самые эффективные алгоритмы, будучи рассмотренными для конкретных сценариев.

Но общий принцип решения "задач о блокировках" — он, считай один.
Других наработок как теоретических, так и в плане иммитационного моделирования, чем СМО на сегодня банально нет.

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

Это перекликается с твоим столь же ожесточённым отрицанием DDD — в разработке сложных современных ПО-систем выжил только этот подход, другие умерли за несостоятельностью.
А этот выжил по простой прчине — является проекцией системного подхода на случай, когда речь сугубо о ПО (в общем случае на наших специальностях натаскивают на разработку аппаратно-программных комплексов, т.е. разработка только ПО — это несколько ограничение "потолка" роста, и это местами немного угнетает... хотя, нехило компенсируется зарплатой... но такова специфика экс-СССР айти).

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


S>То, что вы делаете — это совершенно прозрачная попытка скрыть свои затруднения и непонимание за менторским тоном.

У меня пока одно затруднение — ученик отказывается учиться.
И не в том ученик уже возрасте, когда есть возможность надавить/заставить, через родителей, просто поругать и т.д. ))


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

Ничего не было скипнуто, ля врать-то. ))
Я отвечаю на всё подряд в каждом посте, пока не надоедает.

Обычно набирается твоих 3-5 залётов — и я отправляю тебя на новый круг, бо этот считается непройденным.

Но и это не всё...
Вот это твоё постоянное замыливание, вся эта мышиная возня какая-то мелочная-дурацкая...

Ну какой смысл читать человека дальше, если он в одном абзаце делает некое предположение, порой даже скромным тоном, а в следующих уже рассуждает восю так, будто эти предположения верны? ))
Мляха, 20+ лет стажа на форумах, а ты мне эти "приёмчики" тулишь...
Как от кислого лимона на эту хрень у меня реакция.

И всё больше уверен, что это тупо отлынивание от изучения предмета, банально лень ума.
Хочешь болтать тупо ни о чём? ))

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


S>Мне вот совершенно не стыдно признаться в том, что я не очень хорошо разбираюсь в многопоточном программировании, и, скажем, не могу (в отличие от многих коллег на форуме) сходу ткнуть пальцем в код синхронизации со словами "у вас тут гонка".

А как ты себе вообще представляешь "уметь разбираться в многопоточности"?
Там, вроде, на пальцы одной руки понятий (атомарно/неатомарно, локально/нелокально).
Остальное — банальная внимательность.


S>Зато я хорошо разбираюсь в том, как работают различные СУБД, от игрушечных до промышленных.

И как в этом можно разбираться, не разбираясь в многопоточности?

Путаешь с "ознакомиться с руководством пользователя".

Это как с языком программирования — если сможешь написать для некоего ЯП компилятор-интерпретатор — ты понял этот язык.
Не сможешь — еще не понял.

С СУБД аналогично.
Сможешь их писать, от парсера КС-грамматики SQL, через преобразование/факторизацию уравнений РА (с целью приведения к шагам твоего "плана запроса") и до исполнения этого плана в конкурентной среде — тогда ты понимаешь, что в СУБД происходит. Нет — нет. Тогда ты просто "администратор БД".


S>И разбираюсь я в этом не для того, чтобы унижать людей на форумах — в отличие от вас, мне не стрёмно объяснить кому угодно непонятные места. Я поэтому и преподавать пошёл.

Ты преподаешь ведущим специалистам с 30-тилетним стажем?
Сорри, но не верю.

А может ты лекции читаешь студентам, т.е. минимум доцент?
А на какую темы был диссер, почему не похвастался еще?

Или ты там лаборант/практик?
А мне тут втирать опять изволишь?

Тут же почти все твои собеседники имеют ВО, прекрасно в курсе, что лаборантами/практиками работают даже зеленые аспиранты, которые вот только сами ВУЗ закончили.
Ну и я в ВУЗ-е остался сначала, но в первый же год был вынужден уйти из-за ничтожной ЗП, И? (большое "И")
А корешь остался, правда, ненадолго.

Это таков был "последний аргумент?"

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

В общем, если ты этим прямо заявляешь, что ученик в тебе умер — так можно уже хоронить. ))

(фуф, пипец)