Привет,

подскажите как бы вы решали такую задачу или может библиотеку, которая реализует что-то подобное:
коллекция данных (list/vector) к которой необходимо обеспечить потокобезопасный доступ через "виды".
Вобщем, некий аналог SQL View, когда поверх сырых данных обеспечивается фильтрованный доступ к содержимому коллекции.
Помимо потокобезопасности хотелось бы возможность регистрировать колбек или другой механизм уведомления об изменении.

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

pva>подскажите как бы вы решали такую задачу или может библиотеку, которая реализует что-то подобное:
pva>коллекция данных (list/vector) к которой необходимо обеспечить потокобезопасный доступ через "виды".

я бы делал с помощью акторов. Тут и примеры похожие разбираются https://habr.com/ru/post/322250/

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

pva>>подскажите как бы вы решали такую задачу или может библиотеку, которая реализует что-то подобное:
pva>>коллекция данных (list/vector) к которой необходимо обеспечить потокобезопасный доступ через "виды".
SP>я бы делал с помощью акторов. Тут и примеры похожие разбираются https://habr.com/ru/post/322250/
Да, спасибо, тоже вариант, но не очень понял как натянуть КА-с-подпиской на описанную задачу.
Простейшим примером может быть коллекция структур { имя, возраст } и два "вида" на нее:
1) с сортировкой по имени
2) с сортировкой по возрасту
Можно держать две копии коллекции и синхронизировать операции их изменения.
Можно держать одну коллекцию, а для каждого вида сделать отображение (ключ, ссылка на элемент).
Аналогично и с фильтрами.
Вобщем, вопросы классической СУБД и single reader — multiple writers.
Вот я и подумал: может есть какие-то заготовки под такой типовой сценарий. Например, шаблоны итераторов с перегружаемым методом is_filtered, которые бы бросали исключение в случае инвалидации, а не крашились по access violation. Ну и тому подобное.

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

pva>подскажите как бы вы решали такую задачу или может библиотеку, которая реализует что-то подобное:
pva>коллекция данных (list/vector) к которой необходимо обеспечить потокобезопасный доступ через "виды".

Как бы формулировки задачи как таковой нет Так что сложно понять что именно вам нужно.

Вполне возможно, что вам достаточно будет персистентных (иммутабельных) структур данных.
Например, для C++: https://github.com/arximboldi/immer

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

pva>подскажите как бы вы решали такую задачу или может библиотеку, которая реализует что-то подобное:
pva>коллекция данных (list/vector) к которой необходимо обеспечить потокобезопасный доступ через "виды".
pva>Вобщем, некий аналог SQL View, когда поверх сырых данных обеспечивается фильтрованный доступ к содержимому коллекции.
pva>Помимо потокобезопасности хотелось бы возможность регистрировать колбек или другой механизм уведомления об изменении

Я бы сделал как здесь

Автор: Kernan
Дата: 13.07.22

, только вместо std::mutex следует использовать std::shared_mutex.
Должно получится что-то вроде:

template<typename T>
class SafeData
{
   public:
      template<class Fn>
      auto Transform(Fn&& op) // запись
      {
         std::unique_lock lock( mtx );
         return op(data);
      }
   private:
      template<class Fn>
      auto ConstAccess(Fn&& fnAccess) const
      {
         return fnAccess(data);
      }
   public:
      template<class Fn>
      auto Access(Fn&& fnAccess) // только чтение
      {
         static_assert( ! std::is_reference<decltype(fnAccess(data))>::value, "no references");
         static_assert( ! std::is_pointer<decltype(fnAccess(data))>::value  , "no pointers");

         std::shared_lock lock( mtx );
         return ConstAccess(std::forward<Fn>(fnAccess));
      }
   private:
      std::shared_mutex  mtx;
      T                  data;
};

— осторожно, я это не тестировал и даже не компилировал. Просто эту задачу я бы решал примерно так.

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

BFE>...

По моему, это самое хреновое что можно сделать — лочить всех и вся во время записи, на неопределенное время. Кажется view не так работает. Мы можем взять, условно, слепок контейнера на текущий момент времени и можем модифицировать его как-то, не ограниченно по времени. Потом commit и изменения видят другие. Я конечно не знаю что PVA нужно, приходится гадать.

Как-то приходилось делать такую штуку:
Пишется медиа клип. Данные по размеру сотни гигабайт, короче очень много. Клип может меняться, удаляться и т.д. В любой момент его может открыть неограниченное количество клиентов и они это делают атомарно, т.е. если операция успешна, то клиент получает подобие view, которое от него никуда не денется до закрытия и проигрывать медиа как ему вздумается. Если нужно что-то такое, то нужны дополнительные требования. Например на размер данных, какие операции нужно поддерживать и т.д. Тут все решения будут близки к тому что описал so5team — персистентные иммутабельные хранилища.
Короче в общем виде задача не имеет смысла, из-за требований к памяти, производительности и т.д.

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

V>По моему, это самое хреновое что можно сделать — лочить всех и вся во время записи, на неопределенное время. Кажется view не так работает. Мы можем взять, условно, слепок контейнера на текущий момент времени и можем модифицировать его как-то, не ограниченно по времени. Потом commit и изменения видят другие. Я конечно не знаю что PVA нужно, приходится гадать.
Это не самое плохое, можно ещё и на время чтения всех лочить...
Если коллекции небольшие, а скорости не очень критичны, то такой код подойдёт для очень большого количества задач.

V>Короче в общем виде задача не имеет смысла, из-за требований к памяти, производительности и т.д.
В общем виде эта задача равносильна написанию базы данных, которая работает с данными в памяти: запросы, транзакции и прочая SQLщина. Причём эта задача может быть решена, что называется "в лоб": создаём RAM-диск, прикручиваем какую-нибудь готовую библиотеку, типа SQLite поверх RAM-диска и вуаля, задача решена.

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

BFE>В общем виде эта задача равносильна написанию базы данных, которая работает с данными в памяти: запросы, транзакции и прочая SQLщина. Причём эта задача может быть решена, что называется "в лоб": создаём RAM-диск, прикручиваем какую-нибудь готовую библиотеку, типа SQLite поверх RAM-диска и вуаля, задача решена.

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

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

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

BFE>Я бы сделал как здесь

Автор: Kernan
Дата: 13.07.22

, только вместо std::mutex следует использовать std::shared_mutex.
Да, поддерживаю подобную реализацию MRSW. Впрочем, это только один из аспектов.
Представьте, что у вас есть два визуальных компонента TableView (виртуальная таблица) с различными видами. Очевидно, что стратегия копирования части выборки на каждое обновление видов — не лучший подход.
Да, можно организовать кеширование результата выборки, но все равно при обновлении исходных данных необходимо инвалидировать виды и обновлять.
По сути, мы получаем подход с кучей клонов основной выборки. Если исходный набор велик, то прийдется либо выгружать часть данных, либо использовать изобретать "умные итераторы".

Здесь же в тему серия статей на хабре
https://habr.com/ru/post/328374/

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

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