DPH3Хм, на Java очень богатая библиотека примитивов синхронизации, в том числе атомарные операции, неблокирующие очереди и прочие радости современной науки :)
Стоит их внимательно изучить перед реализацией, там много уже готового.

Теоретически, для курсовой работы, Java - вполне себе язык для разработки БД. Тем более что БД на Java вполне себе есть, даже opensource :)

Проблемы будут со сборкой мусора под нагрузкой, но и они решаемые.

Поверю на слово, скорее всего так и есть: там бы это всё выглядело более строго) Но всё-таки java - не технология для написания БЫСТРОЙ Субд. Компилируемые C/C++ в любом случае быстрее. А мне ведь ещё надо было адекватно сравнить с MySql и прочими)

ЗЫ А атомарные операции поддерживаются на уровне процессора.

авторЭ-э-э... Т.е. ты не читал Рихтера? Там целая глава посвящена именно
разводу читателей и писателей. Двумя мутексами.

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

MasterZiv
smansdb пишет:

> На Java синхронизация многопоточности выполняется элементарно…

Это гон. Она везде одинаково сложна. Не сама синхронизация (она
везде проста), а проектирование приложения таким образом, чтобы
правильно делать синхронизацию.


+1

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


Искал такие алгоритмы, не нашёл. Ну и времени не было. Насчёт блокировки конкретных страниц - это конечно да, но что делать, если страница дерева расщепляется (ну или сливаются две), а другие потоки где-то рядом? Поэтому делал на уровне работы со всем деревом - чтение (может быть много потоков), запись (только 1 поток), unused.

авторЯ фигею, господа. Оказывается есть некий универ, где такая задача это всего лишь курсовой. Если это так, то в стране должны производиться десятки клиент-серверных реляционных СУБД.

Вы считаете, что я лгу? Тема - результат моей самоуверенности, универ - в Минске, БГУИР называется.

автор
проверить + взвести 2 мутекса одновременно. Все это нужно защищать 3-им мутексом на входе.


У меня вообще используется один синхронизирующий примитив - одна спинлок-переменная) Приоритет при синхронизации больше у читателей и это лучше для колоночной СУБД, т.к. они select-ориентированные.
Ладно, пойду искать в Рихтере вышеназванный пример.