Приветствую !

Подскажите как правильно организовать блокировку/синхронизацию потоков если одновременно возможны следующие сценарии доступа к общим данным:

1. (Часто) Много потоков читают, только один поток может писать - напрашивается использование TMultiReadExclusiveWriteSynchrinizer

2. (Редко) один поток эксклюзивно пишет, все остальные потоки (и пишущие и читающие) ждут. Напрашивается использование TCriticalSection

Не совсем понятно каким образом объединить оба сценария в одном планировщике доступа так, чтобы работало максимально быстро и "масштабируемо" ?

При чтении данных нужно проверить нет ли эксклюзивной блокировки (тип 2), если есть - ждать, если нет BeginRead/EndRead у TMultiReadExclusiveWriteSynchrinizer

При обычной записи данных проверить нет ли эксклюзивной блокировки (тип 2) , если есть - ждать, если нет BeginWrite/EndWrite

При эксклюзивной записи данных проверить нет ли эксклюзивной блокировки (тип 2), если есть - ждать, если нет - создать эксклюзивную блокировку, записать, отменить блокировку.

Если с обычным чтением-записью вопрос решается через TMultiReadExclusiveWriteSynchrinizer, то как создавать/проверять эксклюзивную блокировку ? Если использовать TCriticalSection то пропадает смысл в использовании TMultiReadExclusiveWriteSynchrinizer т.к. проверку эксклюзивной блокировки нужно делать при каждом доступе к данным хоть на чтение хоть на запись. С другой стороны, эксклюзивная запись будет достаточно редкой.

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

Спасибо за помощь !

з.ы. Планировщик нужен для многопоточного доступа к БД Sqlite. Мне нужны как обычное чтение-запись в режиме WAL (много читателей, только один писатель), так и эксклюзивная запись когда делаются Create table/drop table и/или модификация служебной таблицы sqlite_master. Свой планировщик нужен для того, чтобы исключить ошибки busy/locked sqlite и таким образом упростить их обработку.

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

Про нормальный бд сервер мы, конечно, думали, но по ряду причин это не подходит.

Флаг не решает проблему.

авторТогда в той же OmniThreadLibrary есть разные блокировки и высокоуровневые объекты под разные режимы работы и синхронизации

Спасибо ! Почитаю их доки !

авторЕсли я правильно понял, то возможно ТС как и я - хотим MREW, но с возможностью VIP прохода

Наверно да. Т.е. нужен MREW, но с постоянной проверкой нет ли эксклюзивной (VIP) блокировки. Если VIP блокировки нет - все работает по MREW, а если есть - то все потоки ждут пока VIP разлочится после чего все продолжает работать по MREW.

VIP блокировки будут довольно редко, но будут.

Уточню по поводу VIP блокировки как я это понимаю:

Если чтение из базы то

BeginRead;
SELECT * FROM...
EndRead;

Если обычная запись в базу то

BeginWrite;
DELETE FROM...
EndWrite;

Если эксклюзиваня запись:

BeginExclusiveWrite;
CREATE TABLE SomeTable...
EndExclusiveWrite;

Таким образом, BeginRead и BeginWrite помимо MREW должны проверять не было ли VIP блокировки (BeginExclusiveWrite). Как эту проверку сделать быстрой и надежной ? Через Interlocked ?

авторуровень вопросов и найденного решения такой, что задачу составил человек, далекий от IT.
Какая задача изначально?

Задача следующая: разрабатывается сервер, предоставляющий API через json-rpc. В качестве движка БД планируется использовать Sqlite т.к. она не требует настройки, не зависима от ОС и не может конфликтовать с сервером БД, который может быть установлен у пользователя. Изначально хотели использовать MySQL или FireBird, но не хочется иметь никаких проблем с деплоем и возможными конфликтами.

авторЧто тут непонятного. Человек хочет захватить мир, используя SQLite.

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

авторВопрос автору -- в чем разница между записью в базу одним потоком и "критической" записью в базу одним потоком? Ведь и там, и там все остальные будут ждать своей очереди.

Смысл в следующем: Sqlite в режиме WAL позволяет параллельно читать данные из множества потоков и писать данные, но только одним потоком. Таким образом нужно чтобы чтение работало параллельно, а запись - через блокировку. Т.е. тут поможет MREW.

Однако, некоторые операции (такие как create table/alter table/drop table а так же модификация таблицы sqlite_master) полностью блокируют и читателей и писателей (ну точнее приведут к ошибкам sqlite_busy и/или sqlite_locked). Таким образом, для этих операций нужна эксклюзивная блокировка когда никакие другие потоки не могут не читать, не писать пока текущий поток не завершит транзакцию. В этом случае нужна критическая секция.

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

авторНо sqlite и так умеет работать в многопоточке.

Умеет, да не совсем. Скажем так, нужно постоянно обрабатывать возможные ошибки busy/locked во всех местах где идет работа с базой. BusyTimeout тоже работает с ограничениями. Цель в том, чтобы разруливать два типа блокировок самостоятельно, что приведет к отсутствию необходимости отлавливать эти ошибки в 500 местах.

авторЧем вложенные крит. секции не подойдут стандартные? ~5 миллисекунд (иногда) критичны?

Тем, что чтение из базы будет по сути в один поток, а это не очень хорошо. Конечно, транзакции стараемся сделать максимально короткими, но тем не менее иногда нужно довольно много читать из большой таблицы. Да, это 3-4 секунды, но в случае критических секций эти 3-4 секунды будут выглядеть как фриз сервера.

авторне понял чем 1 от 2 отличается

Тем что 2 требует полной блокировки всей БД на время пока создаются/удаляются таблицы или модифицируется sqlite_master. Пока это происходит - из базы нельзя вообще не читать, не писать.

авторрасскажи, пожалуйста, что такое "Свой планировщик" - процедура-функция или отдельный поток или отдельный процесс?

Свой планировщик это условно вот-что:

BeginRead;
SELECT * FROM...
EndRead;

Если обычная запись в базу то

BeginWrite;
DELETE FROM...
EndWrite;

Если эксклюзиваня запись:

BeginExclusiveWrite;
CREATE TABLE SomeTable...
EndExclusiveWrite;

BeginRead работает параллельно, BeginWrite - может быть только один, BeginExclusiveWrite - пока установлен то запрещены BeginRead и BeginWrite.

авторТот который эксклюзивно пишет, вначале делает AtomicIncrement(FWrite) и event.reset в конце AtomicDecrement(FWrite); event.set Остальные вначале делают проверку на if AtomicCmpExchange(FWrite, 0, 0) > 0 then ждем сигнал event
и далее разруливаем TMultiReadExclusiveWriteSynchrinizer

ДА ! ДА ! ДА ! Я именно об этом спрашивал ) В данном случае Atomic/Interlocked функции+MREW будут самым эффективным решением ? Или есть какие-то более продвинутые техники (примитивы) синхронизации ?

авторно ведь ты собрался активно выполнять "сreate table/drop table", что мне совсем не нравится.

Не активно, нет ! Изредка. Скажем так: под некоторые "справочники" будут создаться отдельные таблицы и удаляться при удалении справочника. Это будет происходить редко - раз в день, а может и раз в месяц. Тем не менее это иногда будет происходить. Когда это происходит - нужно полностью блокировать базу на чтение/запись из других потоков (а по сути - другими клиентами сервера).

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

авторПри работе с базой данных тип используемого инструмента для блокировок не имеет никакого значения. Все разница в быстродействии исчезнет на фоне работы с данными

Ну смотрите, допустим нужно прочитать 3 миллиона записей из таблицы чтобы составить некий сводный отчет. Если мы используем CriticalSection - все остальные клиенты не смогут ни читать, ни писать пока идет чтение данных. А в случае MREW - остальные смогут читать и только некоторые не смогут писать. Поскольку запись у нас реже чтения - это критично.

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

Тут все правильно. Сама дллка собрана с опцией мультитрединг и какждый поток создает свое подключение к базе. Но ограничение на один пишущий поток и на модификацию sqlite_master - это описано в доках sqlite и это (конкретно в нашем случае) нужно разруливать.

авторДля этого используются временные таблицы.

Насколько я понял из доков Sqlite - временные таблицы удаляются когда закрывается последнее соединение к базе. Т.е. при перезапуске сервера временные таблицы потеряются.

Вот на stackoverflow https://stackoverflow.com/questions/1680249/how-to-use-sqlite-in-a-multi-threaded-application пишут:

Your sqlite3_step, sqlite3_prepare and some other calls may return SQLITE_BUSY or SQLITE_LOCKED. SQLITE_BUSY usually means that sqlite needs to acquire the lock. The biggest difference between the two return values:

SQLITE_LOCKED: if you get this from a sqlite3_step statement, you MUST call sqlite3_reset on the statement handle. You should only get this on the first call to sqlite3_step, so once reset is called you can actually "retry" your sqlite3_step call. On other operations, it's the same as SQLITE_BUSY
SQLITE_BUSY : There is no need to call sqlite3_reset, just retry your operation after waiting a bit for the lock to be released.

Вот ради того чтобы этого избежать все и делается.

В остальном, я думаю, вопрос можно закрывать. Попробуем это:

авторТот который эксклюзивно пишет, вначале делает AtomicIncrement(FWrite) и event.reset в конце AtomicDecrement(FWrite); event.set Остальные вначале делают проверку на if AtomicCmpExchange(FWrite, 0, 0) > 0 then ждем сигнал event
и далее разруливаем TMultiReadExclusiveWriteSynchrinizer

Если не получится или вылезут подводные камни - видимо придется таки переходить на FireBird.

Все большое спасибо за участие и советы !

Большое спасибо ! Попробуем !

авторпосле слов - сreate table/drop table - остается только ставить диагноз творцу

Вы думаете, что create/drop table будет из-за того, что так хочется моей правой ноге ? Нет, все очень внимательно продумывалась и это нужно в силу ряда обстоятельств. И я скажу больше - некоторые большие "справочники" будут в отдельных базах данных т.е. в отдельных файлах, да ) И работа с ними будет через ATTACH DATABASE. Так надо )

авторВсе, что угодно, лишь бы не разбираться в существующей системе.

Читаем это:

авторYour sqlite3_step, sqlite3_prepare and some other calls may return SQLITE_BUSY or SQLITE_LOCKED. SQLITE_BUSY usually means that sqlite needs to acquire the lock. The biggest difference between the two return values:

SQLITE_LOCKED: if you get this from a sqlite3_step statement, you MUST call sqlite3_reset on the statement handle. You should only get this on the first call to sqlite3_step, so once reset is called you can actually "retry" your sqlite3_step call. On other operations, it's the same as SQLITE_BUSY
SQLITE_BUSY : There is no need to call sqlite3_reset, just retry your operation after waiting a bit for the lock to be released.

Т.е. возможны два вида ошибок у TQuery.Prepare, TQuery.Open, TQuery.Next и DataBase.StartTransaction/Commit. И в одном случае нужно переоткрыть запрос, а в другом пытаться еще несколько раз по таймеру. Если же самому управлять тем как потоки читают/пишут в базу можно полностью, с гарантией 100% исключить проблемы с busy/locked и не контролировать эти ошибки везде в коде где идет работа с базой.

авторЖесть... Еще больше уверен, что нужен толковый архитектор.
Либо это саботаж.

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

авторНет никакой "проблемы" с busy/locked, это ШТАТНОЕ поведение, а не ошибки. И это поведение позволяет продолжить вычислительный процесс, а не перевести в тупое состояние ожидания доступности базы. Ты, если и реализуешь свой "диспетчер", в итоге в придешь к тому же самому (в лучшем случае).

Может и нет если работать с sqlite api напрямую. Но мы работаем через LiteDac/TDataSet, а для TDataSet это "штатное" поведение не является штатным.

Вообще вопрос был про многоуровневую синхронизацию потоков. Sqlite или нет - не имеет значения. Кто-то кроме X-Cite знает как это сделать ? Советчики архитекторов и учителя работать с sqlite не нужны :-)

Спасибо ! Попробуем !