SB
Проблемы только с менеджером памяти при очень интенсивном использовании (тысячи команд в секунду), тогда за неделю-месяц проявляются всякие нехорошие вещи вроде фрагментации памяти кучи, недостаток хендлов и квантовые эффекты освобождения строк.
Size: a a a
2020 December 02
SB
такие проблемы решаются постоянными (заранее созданными) элементами и строками.
GB
Проблемы только с менеджером памяти при очень интенсивном использовании (тысячи команд в секунду), тогда за неделю-месяц проявляются всякие нехорошие вещи вроде фрагментации памяти кучи, недостаток хендлов и квантовые эффекты освобождения строк.
что за "квантовые эффекты освобождения строк"?
SB
что за "квантовые эффекты освобождения строк"?
Например, если OnPaint происходит отрисовка строки, а в это время менеджер памяти в другом потоке ее освобождает.
VA
Например, если OnPaint происходит отрисовка строки, а в это время менеджер памяти в другом потоке ее освобождает.
как много секретов мы еще не знаем...
SB
как много секретов мы еще не знаем...
Это редкое явление, я его пару лет ловил. Потом создал пример с гарантированным срабатыванием в TListView.OnData.
VA
Это редкое явление, я его пару лет ловил. Потом создал пример с гарантированным срабатыванием в TListView.OnData.
сорян, но с учетом двойного срабатывания Execute у потока - не верю (с)
SB
сорян, но с учетом двойного срабатывания Execute у потока - не верю (с)
Убери CriticalSection и убедись
VA
dfm забыл
VA
Убери CriticalSection и убедись
ес-но общие данные между потоками должны синхронизироваться
вообще конечно нужно время, чтобы понять твою демку
вообще конечно нужно время, чтобы понять твою демку
z
а что за причины? навскидку никаких проблем не вижу, только в commandManager надо будет поменять, чтоб учесть, что из другого потока с UI взаимодействие идет
Они должны менять данные в основном потоке. Придется делать целую прослойку для совместного использования данных. Кроме того, это единственная причина для многопоточности)) проблем с производительностью нет, распаралеливать ничего тоже ненадо
z
Они должны менять данные в основном потоке. Придется делать целую прослойку для совместного использования данных. Кроме того, это единственная причина для многопоточности)) проблем с производительностью нет, распаралеливать ничего тоже ненадо
На данном этапе причин имею ввиду
VA
у тебя синхронизация криво сделана даже в текущем варианте
если оно и работает - то только по чистой случайности
если оно и работает - то только по чистой случайности
SB
у тебя синхронизация криво сделана даже в текущем варианте
если оно и работает - то только по чистой случайности
если оно и работает - то только по чистой случайности
Оно специально криво сделано, чтобы определить границы дозволенного.
z
Я бы сделал очередь (или стек) команд. По таймеру или внутри фонового потока, брать из очереди команды по одной и выполнять. Если попалась интерактивная команда, требующая действия пользователя, то ставить на очередь признак паузы, пока не будет получен ответ пользователя, который добавляется в голову очереди как команда.
Т.е. за многопоточность
Д
Оно специально криво сделано, чтобы определить границы дозволенного.
Это по принципу: Я знаю отличную шутку про UDP но не факт, что она до вас дойдёт...
VA
Оно специально криво сделано, чтобы определить границы дозволенного.
это как и зачем?
зачем ты тогда пишешь про "Убери CriticalSection"?
вся UpdateListItem должна быть в локе
зачем ты тогда пишешь про "Убери CriticalSection"?
вся UpdateListItem должна быть в локе
VA
общий лок по аналогии с
RandomizeItem
ну а уж если и вообще убрать локи, то конечно будет каша.SB
это как и зачем?
зачем ты тогда пишешь про "Убери CriticalSection"?
вся UpdateListItem должна быть в локе
зачем ты тогда пишешь про "Убери CriticalSection"?
вся UpdateListItem должна быть в локе
Раньше был один общий лок на весь список, который использовался и при чтении элементов, и при обновлении. Но этого оказалось недостаточно. Вот я и экспериментировал.