Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[3.139.72.78] |
|
Страницы: (2) 1 [2] все ( Перейти к последнему сообщению ) |
Сообщ.
#16
,
|
|
|
Цитата Pavia @ Если у каждого потока будет своя корпия данных, то никаких конфликтов соответственно не будет. Но я бы данные удалил из списка. И только после этого снял Lock. Вот я примерно к этому и прихожу. Пока придумал такую схему: - в потоке ридера будет два TThreadList - один для пустых кадров, один для заполненных - будет две public процедуры - в одной ищется кадр с нужным таймстемпом, он удаляется из листа заполненых кадров и отдаётся в основной поток. Всё, кадр недоступен для потока ридера, конфликты невозможны. - вторая процедура будет возвращать отработанный кадр в лист пустых кадров - в потоке ридера в основном цикле будет проверяться - "lock" есть ли кадры в листе пустых кадров, если есть, то пустой кадр забирается из листа пустых кадров "unlock" -> заполняется полученный пустой кадр -> "lock" -> кадр добавляется в лист заполненных кадров -> "unlock". Вроде обещают, что да. Цитата Pavia @ Вам придётся в каждом публичном методе сделать синхронизацию, а именно вставить критическую секцию. Ну да. То есть в первой процедуре будет "lock - unlock" листа заполненных кадров, во второй - "lock unlock" листа пустых кадров. Пока не вижу - где здесь может возникнуть дидлок. |
Сообщ.
#17
,
|
|
|
Очень спорно. Если все кадры одинакового размера, то массив preallocated буферов и простейшая обертка над ним, предоставляющая интерфейс очереди, и никакого менеджера не нужно. Очень-очень спорно. Больше с IPC запаришься. Добавлено Цитата An_private @ Иди лучше всё-таки при запросе кадра копировать его в новый буфер и отдавать этот буфер основной программе, а программа уже сама его очистит когда не надо? Тут я просто боюсь проблемы фрагментации памяти - каждый кадр будет примерно по 4 МБ и 25 раз в секунду просить от системы по 4МБ и тут же их отдавать - не будет ли проблем. Я правильно понял - задача потока фреймсервера только и состоит, что в асинхронном чтении файла и выдаче нужного кадра по запросу главного потока? В таком случае никаких сложностей, фреймсервер просто возвращает ссылку на свой буфер, возможно даже синхронно, т.е. ждет, пока главный поток не отпустит кадр. Все равно же ему в это время не надо ничего делать. Соответственно крит. секция одна на фреймсервер, ну или можно заменить на event по желанию. |