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

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

Да ля вертеться-то, это именно таков обмен "аргументами".
Забористая каша, плаваешь в терминах, плохо представляешь себе происходящее в СУБД.


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

Какой именно задачи? ))
Прежде чем проcить решение задачи, задачу надо сформулировать.
С этим ты не справился пока.


S> — вы начали с описания некоего решения на основе семафора;

"Некоего решения"

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

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

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

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


S>затем оговорились, что это решение — плохое, поэтому нужно добавить ещё один семафор, впрочем это решение тоже плохое, поэтому нужно использовать пользовательские очереди задач.

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

Фактор голодания писателей важный и был приведён не просто так, бо в СУБД ситуация аналогичная и об этом тоже упоминалось — операций чтения всегда намного больше операций записи.
А в условиях проверки целостности, даже если в данный момент поступают лишь построчные операции записи в базу, то на запись одной строки приходится производить огромное кол-во чтений.

Всё это озвучивалось, просто ты порой потрясающе невнимателен.


S>При этом изо всего этого ряда решений код вы привели только для первого, и то неполный, а в стиле "вот вам int main(){}, остальное впишите между фигурными скобками".

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

Если уж приводить аналогию, то тебе дали ф-ию, допустим, ssize_t read(fd, void *, size_t) и сказали — теперь ты сможешь прочитать файл построчно, при надобности.

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

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

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

Да ля вертеться-то, это именно таков обмен "аргументами", твои цитаты дословные.
Вот два твоих последовательных поста:
http://www.rsdn.org/forum/flame.comp/8109346.1
http://www.rsdn.org/forum/flame.comp/8111608.1

Забористая каша, плаваешь в терминах, плохо представляешь себе происходящее в СУБД.

Но тех цитатах забавны даже не сами они, а их "последовательность", бгг...
За подобный уровень как владения материалом, так и навыков обмена аргументацией должно быть невыносимо стыдно, ИМХО.


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

Какой именно задачи? ))
Прежде чем проcить решение задачи, задачу надо сформулировать.
С этим ты не справился пока.

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

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


S> — вы начали с описания некоего решения на основе семафора;

"Некоего решения"

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

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

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

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


S>затем оговорились, что это решение — плохое, поэтому нужно добавить ещё один семафор, впрочем это решение тоже плохое, поэтому нужно использовать пользовательские очереди задач.

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

Фактор голодания писателей важный и был приведён не просто так, бо в СУБД ситуация аналогичная и об этом тоже упоминалось — операций чтения всегда намного больше операций записи.
А в условиях проверки целостности, даже если в данный момент поступают лишь построчные операции записи в базу, то на запись одной строки приходится производить огромное кол-во чтений.

Всё это озвучивалось, просто ты порой потрясающе невнимателен.


S>При этом изо всего этого ряда решений код вы привели только для первого, и то неполный, а в стиле "вот вам int main(){}, остальное впишите между фигурными скобками".

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

Если уж приводить аналогию, то тебе дали ф-ию, допустим, ssize_t read(fd, void *, size_t) и сказали — теперь ты сможешь прочитать файл построчно, при надобности.

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

Мне от собеседника требуется демонстрация хоть какого-то понимания и не самого низкого уровня сообразительности.
Если человек не сможет через read и небольшой буфер сам, без подсказок, написать алгоритм построчного чтения файла, ему лучше сходу слиться.