Так ведь Synchronize нужна, чтобы предотвратить одновременный доступ к одному и тому же объекту. В моей программе только поток чтения обращается к объектам

Form1->Nsect=Form1->Data.RecByte1
                        Form1->Fh=(Form1->Data.RecByte2)+((Form1->Data.RecByte3)*255);
                                        
                        Form1->Label20->Caption=IntToStr(Form1->Data.RecByte1);
                        Form1->Label21->Caption=IntToStr(Form1->Data.RecByte2);
                        Form1->Label23->Caption=IntToStr(Form1->Data.RecByte3);
                        Form1->Label24->Caption=IntToStr(Form1->Fh); 



, а чтобы не случилось проблем я и пытаюсь притормаживать поток чтения.

Synchronize нужна всегда, когда обраащешься к визуальным компонентам (Form, Label и т.д.) потому что есть ещё основной поток твоей программы, и когда он там к чему обратится неизвестно (событий же куча). Поэтому надо синхронизировать. Попрбуй сделать как я написал, может висяки исчезнут.
Да и здесь на форуме есть несколько тем, где это более-менее описано. А к данной теме синхронизация очень отдалённо относится

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

Фишка еще вот в чем -
когда убираю функции Suspend и Resume, то все работает нормально - и чтение идет и запись, но как-то это не красиво: при записи в порт надо остановить чтение. Пока не придумал как.

Если Вы используете FreeOnTerminate = true, то после Resume() вообще обращаться к как либо к объекту TThread  обращаться  опасно. К тому времени, когда Вы  попытаесь обратиться, вполне возможно, что он уже завершился и в о


Вольный перевод


Что касается использования  WaiteFor, то все очень просто.   WaitFor как раз должен следовать за Resume, но не следующей сточкой 

То есть в отличие от вашего кода мы имеем участок, когда идет паралельное выполнение в основном и дочернем потоке. А WaiteFor() в данном случае приминяется для синхронизации этих потоков. Мы же не знаем, кто завершит свой код раньше основной поток или дочерний. Но такое поведене справедливо при FreeOnTerminate= false

Читаем: 
TThread::Terminate
Signals the thread to terminate by setting the Terminated property

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

Причем тут это? Вы вводную читали?

Поток успевает завершиться сам, а не принудительно через Terminate. И таких задач, где нет бесконечного цикла  навалом. Если Вы не встречали в своей практике, это еще не значит, что их нет. 
Так что Ваш код для данного случаЯ ошибочен. Поток во-первых может завершиться сам до вызова Terminate. 
Ну а если Вы этот же код используете у себя и при этом у вас есть цикл с проверкой Terminated и FreeOnTerminate == true, то код  


опасен все равно. Потому что есть вероятность, что Вы можете схлопотать эксепшен на вызове WaitFor(). Надеяться на то, что между вызовами Terminate и WaitFor объект не успеет разрушится, неразумно. Если уж очень хочется обнулить td то логичнее и безопаснее смотрелось бы
 


 
 

У меня основной целью было не обнулить td, а чтобы не росла занимаемая программой память из-за постоянно создаваемых потоков.
В принципе я уже переделал основные потоки, к-рые создаются моей программой, по типу бесконечной петли обработки, но есть ещё поток, который создаётся время от времени.
 
О, прямо сейчас придумал! А если и этот поток делать как бесконечную петлю обработки, но, поскольку он должен выполняться эпизодически, ввести дополнительное условие:

А флаг просто менять из того потока, который должен активировать этот

тебе не надо ничего придумывать. вместо этого лучше прочитай пару-тройку статей про потоки и синхронизацию.

твой поток можно сделать, например, так:


когда нужно, чтобы рабочий поток выполнил "...", в основном потоке делаешь:

Да, суть та же, только писанины больше. Всё равно же, все эти апишные функции (как впрочем и все), по сути - обёртки для обычных mov eax, ecx   (в нашем случае - mov flag, 1). А, по-моему, чем проще, тем надёжнее и быстрее