Да, именно так



Посадить потоки на TThread, или вручную реализовать то, что сделано в TThread::Synchorize. А именно -

1. Данные помещаются в очередь (можно просто переменная)
2. Главному окну посылается специальное сообщение (любое)
3. WaitForSingleObject(sync_event)

В обработчике специального сообщения главного окна:

1. Забираем данные, рисуем
2. SetEvent(sync_event)

Event sync_event должен быть создан как

Не так.
Поток приема из УАРТа.

1. Ждем стартовый байт. (WaitCommEvent(), WaitForSingleObject())
2. Входим в критическую секцию. (EnterCriticalSection()) - не надо, больше никто всё равно не читает из порта.
3. Записываем данные в буфер. (ReadFile())
4. Выходим из критической секции. (LeaveCriticalSection())
5. Распределяем память под принятое количество байтов и копируем туда принятое;
6. Отправляем указатель на этот блок памяти в главное окно при помощи PostMessage(WM_USER+3);
7. Устанавливаем событие в сигнальное состояние (событие с автосбросом) (SetEvent()) - это тоже лишнее, поскольку мы отправили сообщение сразу в главное окно и никто не спит, дожидаясь данных.
8. Переходим к п. 1.

Основной поток программы:

1. Ждем сообщения WM_USER+3;
2. Берём данные из указателя - параметра, отрисовываем их.
3. Уничтожаем память под указателем.
4. Переходим к п. 1.

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

Да, и делать 2 дополнительных потока это тоже перебор, вполне хватит и одного - для приема. Обработку и отрисовку можно делать в главном потоке приложения.

Ерунда. Не те объёмы. Да и блоки скорее всего фиксированной длины.



Ну а я как написал?

Скорее всего, это адресовалось мне.


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

Т.к. следующее предположение верно, то можно ведь изменить пункт

на "один раз выделили в начале и потом просто пользуемся этим указателем до конца работы".

Попутно вопрос: сейчас данные приходят через фиксированные промежутки времени, данные успевают обработаться за это время, и поэтому, как я понимаю, хватает одной ячейки во втором буфере. А теперь представим ситуацию, когда данные приходят нерегулярно. Тут уже потребуется FIFO с достаточным количеством ячеек?

Да, это как раз очень подходящий пример.



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



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

Теперь ясно. Я не так понял "Распределяем память под принятое количество байтов и копируем туда принятое". Почему то подумал, что это всегда будет одна и та область памяти. А тут мы каждый раз выделяем новую, но при этом указатели на старые куски данных могут быть еще валидными. Ну, и таким образом отпал вопрос о не успевании программы.

На форуме мастеров делфи. http://www.delphimaster.ru/