на данный момент ситуация такая:
- главный поток подключается к sqlite3 и использует 1 файл базы.
- запускается Н потоков, они все подключаются к этому же sqlite-файлу и вносят в него изменения

сначала пробовал один раз подключиться к базе, а потом юзать соединение из потоков
sqlite запрещает - пишет что нельзя использовать базу, подключенную в другом потоке

потом стал создавать новые подключения в каждом потоке
начал глючить, типа база залочена
решилось использованием Lock()

теперь проблема в том, что когда потоков много - лезет ошибка “unable to open database file”

попробовал сделать очередь Queue, так чтобы потоки кидали в неё задания на изменение базы, а главный поток эти задания обрабатывал и сам работал с базой

и вот в чем проблема: делать всякие insert, update удобно, но как получать данные из базы в потоки?

например в базе есть таблица tasks и 100 потоков берут из таблицы рандом-строки, выполняют их и помечают в базе как выполненные

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


т.е получается, для того чтобы брать из базы рандом строки потоками - все же требуется в каждом потоке создавать подключение к файлу базы
что нам дает “unable to open database file” если потоков много

можете предложить иной способ работы с бд?

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

Игнат
100 потоков берут из таблицы рандом-строки

Игнат
теряются преимущества базы по сортировке, выборке

Что-то я не понял, вам случайные строки нужны или все таки в каком-то порядке?

Пусть главный поток формирует очередь по нужным вам правилам и оптимальной для вашего случая длины.
Дочерние потоки будут брать задачи из этой очереди и помещать обратно результат.
Обработанная задача помечается главным потоком как выполненная.
Периодически (или по какому либо критерию) очередь пополняется новыми задачами из базы.

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

ЗЫ
Я на собеседованиях ожидаю минимум 2 варианта из 4 известных мне услышать :)

да, использование mysql слишком хлопотно при переносе скрипта. он должен быть мобилен

два варианта - либо случайные, либо по очереди
но больше случайные

к сожалению, у меня нет знаний подобных алгоритмов
можете подсказать что погуглить?

Возьмите пока самый простой вариант: свободный поток лочит очередь, забирает 1 задачу, освобождает лок, работает с задачей и т.д по кругу.
Формирование очереди описано выше.