to Igors:
Почитайте про Model/View.
1) Все операции с контейнером который имеется лишь в наследнике, производятся ТОЛЬКО в наследнике.
2) Все операции производимые моделью берут данные из переопределённых методов, т.е. ColumnCount/RowsCount/Data.
3) Что модель не обрабатывает данные, а лишь отдаёт данные по сигналу View.
4) Никто не гарантирует что всё не изменится, если изменится в любом случае придётся переписывать, и ваши "предположения" ни к чему не приведут.
5) UI не дёргается на каждый чих. Дёргается только модель, а View обновляться будет с нормальной частотой и по необходимости. Это опять таки написано в пунктике Model/View.

- феерический бред. Модель работает с данными. Все методы работы с контейнером переопределены правильно, и как следствие нужно ставить мутекс только на них.

PS мне вот лично интересно как paint View может повлиять на данные в модели?

Спасибо, Igors. Ваш код помог. Правда как только я вместо QAbstractTableModel стал использовать QSortFilterModel, то проблема вернулась, несмотря на то, что я перед функцией filterAcceptRow ставлю CScopedLock lock(m_Lock).

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

Просто надо пользоваться функциями модели, защищёнными мутексами и будет всё хорошо. Мутексы гораздо быстрее обновления ui. Хотя конечно зависит от нагрузки.

PS ну если конечно написать model->m_rowList[1], то будет вылет.

Блокировка происходит в модели. Пока там мутекс не освобождён стоит всё. И paint вызывает data, который ставит Mutex и который отдаёт данные. В один момент времени могут быть отданы данные, или же изменены данные. А т.к. данные нетяжелые и скорость изменения данных очень высока, то пользователь не заметит даже разницы работы модели с мутексом или без.

Model и View связаны сигналами, которые сами разруливают проблемы с Queued connection. Хотя тут тоже вопрос, смотря в какой момент будут они связаны и какой тип соединения будет использован.

PS хотя конечно не стоит так делать с потоками - потоки этого не любят, ну или по крайней мере, не одобряют.

QModelIndex это просто циферки row и column для вызова функции Data или Remove или Insert.
Ставим мутекс в Data и мы защищены от ВСЕХ читающих.
Мутексы поставленные в ф-ции запроса, добавления, изменения и удаления данных защищают данные.

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

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

1) удаляется 5 строка.
2) Проходит захват мутекса делегатом для отрисовки 5 строки.
3) Проходит проверка на валидность индекса. На этой части он получает отлуп - пятой строки уже не существует и её удаление произведено корректно.
4) View получает QVariant().
5) Отрисовывает пустой поле.
6) Тут приходит сигнал об удалении в модели.
7) View удаляет ненужную строку.
Работа завершена корректно, пользователь увидел лишь удаление строки.

Мм?
Вы хотите сказать, что переопределяя метод data(), проверку на валидность индекса в контейнере делать не надо? Пусть даже топорным
Или же вы никогда не проверяете наличие яблок в пакете, беря яблоко?