Использование TThread , Можно ли использовать TThread для создания и добавления объекта в список

[An_private]

Цитата Pavia @ 03.06.17, 17:37

Если у каждого потока будет своя корпия данных, то никаких конфликтов соответственно не будет. Но я бы данные удалил из списка. И только после этого снял Lock.

Вот я примерно к этому и прихожу. Пока придумал такую схему:
- в потоке ридера будет два TThreadList - один для пустых кадров, один для заполненных
- будет две public процедуры
- в одной ищется кадр с нужным таймстемпом, он удаляется из листа заполненых кадров и отдаётся в основной поток. Всё, кадр недоступен для потока ридера, конфликты невозможны.
- вторая процедура будет возвращать отработанный кадр в лист пустых кадров
- в потоке ридера в основном цикле будет проверяться - "lock" есть ли кадры в листе пустых кадров, если есть, то пустой кадр забирается из листа пустых кадров "unlock" -> заполняется полученный пустой кадр -> "lock" -> кадр добавляется в лист заполненных кадров -> "unlock".

Цитата Pavia @ 03.06.17, 17:37

А она потока безопасна?

Вроде обещают, что да.

Цитата Pavia @ 03.06.17, 17:37

Вам придётся в каждом публичном методе сделать синхронизацию, а именно вставить критическую секцию.

Ну да. То есть в первой процедуре будет "lock - unlock" листа заполненных кадров, во второй - "lock unlock" листа пустых кадров. Пока не вижу - где здесь может возникнуть дидлок.

[Fr0sT]

Цитата Pavia @ 03.06.17, 17:37

с вероятностью 90% вам в любом случае придётся писать свой менеджер памяти

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

Цитата Pavia @ 03.06.17, 17:37

Лучше просто раскидать не по потокам, а по процессам.

Очень-очень спорно. Больше с IPC запаришься.

Добавлено 13.06.17, 08:44

Цитата An_private @ 03.06.17, 15:07

Иди лучше всё-таки при запросе кадра копировать его в новый буфер и отдавать этот буфер основной программе, а программа уже сама его очистит когда не надо? Тут я просто боюсь проблемы фрагментации памяти - каждый кадр будет примерно по 4 МБ и 25 раз в секунду просить от системы по 4МБ и тут же их отдавать - не будет ли проблем.

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