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

V>Забористая каша, плаваешь в терминах, плохо представляешь себе происходящее в СУБД.
Вот вы же себя сейчас описываете.


S>>Я вас просил привести решение задачи

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

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

Видите, с чего всё начинается? Я вам пытаюсь объяснить простую вещь: себестоимость поддержки изоляции транзакций на фоне затрат на интерпретацию планов запросов. Вы — не вьезжаете, и начинаете писать чушь.
В следующем посте я уточняю область моей обеспокоенности:

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

Вот она, эта задача. Все самописанные "быстрые" приложения поверх локальных СУБД работают в недостижимых для сервера приложений тепличных условиях — например, однопользовательский режим работы (и однопоточный движок исполнения транзакций), и рудиментарыне возможности по восстановлению после сбоев.
Механизмы обеспечения A, I, и D в ACID хорошо известны и изложены в той самой литературе, которую вы избегаете читать (но регулярно пытаетесь отправить её читать меня).
Вопрос — в себестоимости этих механизмов.

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

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

V>Всё это озвучивалось, просто ты порой потрясающе невнимателен.
Ну так а толку всё это озвучивать, когда эти факты никакого влияния на ход вашего решения не оказывают? Ваш семафор не умеет делать банальную конверсию read lock в write lock. Голодание писателей — это десятая по важности проблема после базовой функциональности, без которой о реализации изоляции транзакций в СУБД и заикаться нечего.
Для интересу, можете ознакомиться с тем, что происходит в настоящих СУБД на примере вот этой статьи.
Там упрощённый псевдокод, но он даёт ровно то, что нужно — понимание, какие операции выполняются, где синхронизация, где interlocked. Можете сравнить со своим кодом, который одновременно слишком низкоуровневый, и слишком "общий".
Кроме псевдокода можно посмотреть на то, какие факторы влияют на быстродействие механизма блокировок. В частности, как раз те самые операции над списками блокировок, о которых у вас вообще не упомянуто — и ровно потому, что вы понятия не имеете, что и зачем вынуждены делать реальные СУБД. На фоне вот этих приседаний ваша экономия легковесным семафором — спички.


V>Тебе привели ключевое — как писать свои примитивы синхроизации для кода, работающего поверх выталкивающей многозадачности.
)

V>Твои возмущения "да я не вижу здесь кода построчного чтения файла" воспринимаются до поры до времени с нисходительностью...
V>Но в какой-то момент обязательно пошлют, не переживай. ))
Да я и не переживаю. Мне просто интересно, чем это кончится. У вас же есть два режима общения. Один — это кривляния. Для меня они заходят в качестве вечернего развлечения, вроде comedy club.
А второй режим — когда вы внезапно перестаёте выделываться и пишете по делу.
V>Если человек не сможет через read и небольшой буфер сам, без подсказок, написать алгоритм построчного чтения файла, ему лучше сходу слиться.
Видите ли, чтобы претендовать на позицию учителя, нужно быть готовым самому "сесть за руль". Но вот за вами такой готовности незаметно — ни в этом топике, ни в каких других. У вас всегда наготове критика, переваливание ответственности на других, и смелые заявления "я бы сделал лучше". Вот только наблюдаемый результат — это либо ссылки на ноу-хау, либо "я вам дал подсказку, дальше сами". Фу таким быть.
То, что вы делаете — это совершенно прозрачная попытка скрыть свои затруднения и непонимание за менторским тоном.
И определяется это очень легко — можно просто брать любой ваш ответ и сравнивать с тем постом, на который он отвечает. Вот скипнутые вами вопросы — и есть те места, в которых вы плаваете, а признаться стрёмно.

Мне вот совершенно не стыдно признаться в том, что я не очень хорошо разбираюсь в многопоточном программировании, и, скажем, не могу (в отличие от многих коллег на форуме) сходу ткнуть пальцем в код синхронизации со словами "у вас тут гонка". Зато я хорошо разбираюсь в том, как работают различные СУБД, от игрушечных до промышленных. И разбираюсь я в этом не для того, чтобы унижать людей на форумах — в отличие от вас, мне не стрёмно объяснить кому угодно непонятные места. Я поэтому и преподавать пошёл.