Потокобезопасная QStandardItemModel

[Serr500]

Можно ли как-то сделать потокобезопасную QStandardItemModel?

[Bepec]

Пару мутексов и всё нормально, не?

[Igors]

Пару мутексов и всё нормально, не?

оптимизм * компетентность = константа
 

[Serr500]

Пару мутексов и всё нормально, не?

Не. Model-Based Widgets вызывают всяческие методы QStandardItemModel. Что именно защищать мьютексами?

[Igors]

Интересный вопрос. Поскольку вьюшка держит указатель на модель (поправьте если не так) то сделать "в общем виде" не получается. С др стороны thread-safe контейнер - вполне реально и не так уж сложно. Может быть ограничиться проверкой флага "запись" и выбрасывать assert во всех методах вызываемых из UI, ну и перед отдачей ему управления выставить "чтение", с тем чтобы пишущие ждали пока UI отработает

[Serr500]

Мда... Что-то сложно всё получается... Попробую как-нибудь обойтись без обращения к модели из разных потоков...

[Bepec]

Кхм. Я конечн многого могу не понимать, но чем потоконебезопасно обращение к модели из разных потоков, если контейнер данных защищён мутексами?
Все стандартные методы в своей модели не оперируют с данными. Максимум чтение.
А удаление/добавление/изменение производится с помощью переопределённых функций, которые и можно защитить мутексами, не?

update:
ОМММ... Мари рама...
Я всегда буду читать название темы 2 раза!
Я всегда буду читать название темы 2 раза!
Я всегда буду читать название темы 2 раза!

[Igors]

Кхм. Я конечн многого могу не понимать, но чем потоконебезопасно обращение к модели из разных потоков, если контейнер данных защищён мутексами?

Ну а что такое "потокобезопасный контейнер"? Задумывались ли Вы почему таких классов особо не видно? Пример

Код

C++ (Qt)
for (it = vec.begin(); it != vec.end(); ++it)
 // что-то делаем
 
// или даже просто так
T & val = vec[i]; 
 

Если др нитка полезет с vec.erase (resize, insert и.т.п. - запись) то ссылки и итераторы в тексте выше станут невалидными. Это вроде легко решается установкой локов, но это должно делаться на стороне вызывающего, не видно как вшить это в сам контейнер. Как он может знать когда возвращенная ссылка/итератор больше не нужна и можно разрешить  запись?

Ну и получается что надо лочить все обращения, а как это сделать если они внутри либы в 100 местах?

[CuteBunny]

Мда... Что-то сложно всё получается... Попробую как-нибудь обойтись без обращения к модели из разных потоков...

А если попробовать через QSharedPointer?

[Serr500]

А как Shared Pointer защитит от одновременных обращений из разных потоков? QSharedPointer это простенький контейнер со счётчиком ссылок, который удалит объект, когда счётчик обнулится.

[CuteBunny]

А как Shared Pointer защитит от одновременных обращений из разных потоков? QSharedPointer это простенький контейнер со счётчиком ссылок, который удалит объект, когда счётчик обнулится.

Ну судя, по документации, операции, осуществляемые над значением, на которое указывает qsharedpointer, потокобезопасны, если я всё правильно понял.

QSharedPointer and QWeakPointer are thread-safe and operate atomically on the pointer value. Different threads can also access the QSharedPointer or QWeakPointer pointing to the same object at the same time without need for locking mechanisms.

It should be noted that, while the pointer value can be accessed in this manner, QSharedPointer and QWeakPointer provide no guarantee about the object being pointed to. Thread-safety and reentrancy rules for that object still apply.

[DmitryM]

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

[Serr500]

Ну судя, по документации, операции, осуществляемые над значением, на которое указывает qsharedpointer, потокобезопасны, если я всё правильно понял.

Правильно. То есть изменение указателя в QSharedPointer атомарно и потокобезопасно. Но указатель у меня не меняется. Этот указатель передаётся во вьюху, которая вызывает методы экземпляра класса, представленного указателем. Вьюха тем самым обращается к данным, содержащимся в модели. Из другого потока во время обращения к данным может быть вызван метод, эти данные изменяющий. В результате в процессе выполнения метода, вызванного из вьюхи, данные искажаются и приложение падает. (В моём случае вызывается метод поиска родителя, который уже удалён.)

P.S. Посмотрел сейчас на реализацию QAbstractItemModel. Контейнер там прячется где-то в приватной части класса и доступа к нему нет. То есть даже создать собственную потокобезопасную модель на его основе не удастся.

[Авварон]

P.S. Посмотрел сейчас на реализацию QAbstractItemModel. Контейнер там прячется где-то в приватной части класса и доступа к нему нет. То есть даже создать собственную потокобезопасную модель на его основе не удастся.

МОжет QStandardItemModel? лень смотретть в сорцы, но какой контейнер может быть в абстрактной модели?

[DmitryM]

Как вариант сделай какой-нибудь ThreadSafeTable и его помести в QAbstractItemModel