Просто Трёп [игнорируется] 
Можно посылать сообщения потоку функцией PostThreadMessage. Тогда, если в потоке нет своего цикла обработки сообщений, его надо организовать при помощи например функции PeekMessage.

Насчёт евентов - это хороший вариант, но надо понимать, что поток, который будет ожидать срабатывания события при помощи функции WaitForSingleObject или WaitForMultipleObjects, будет в состоянии ожидания.

Службы никогда не писал (вроде, не припоминаю такого :) ) не особо представляю, что там удобно.

Если сообщения, то посылать можно из любого потока любому. Но чтобы поток мог принимать их, в нем должен быть цикл обработки сообщений. Вот в обычном Windows приложении на Delphi в главном потоке такой цикл уже есть, его VCL реализует.
Насчет событий, ну в моей практике отношения между потоками обычно были несимметричными. Например один поток подготавливает какие-то данные и выдает другому, чтобы тот передал их по сети. Или один поток всё время обменивается данными с каким-то устройством и периодически или сам их выдает или у него запрашивают какие-то данные.
Вот кстати со скуля один человек учебник написал несколько лет назад про многопоточность:
https://github.com/loginov-dmitry/multithread/blob/master/multithread_in_delphi_for_beginners.md

https://resql.ru/forum/topic.php?fid=58&tid=2036872
Правда не скажу сейчас, насколько хорошо написано, хотя начинал читать.

Да не особо тяжеловесный. Я сам правда один раз с этим дело имел, и то, другой человек делал, а я подрихтовывал. Сообщения через PostMessage, PostThreadMessage хороши тем, что асинхронная обработка - один поток не ждет, пока второй обработает сообщение. Добавил сообщение в очередь и дальше занимается своими делом. А с критическими секциями могут быть коллизии, когда один поток ждет другой. Но да, критические секции - норм, тоже ими не раз пользовался.
Неизвестно, что за служба у Просто Трепа и что за обмен данными там между потоками.

p.s. Один раз - сообщения от потока в другой доп. поток, так что там цикл обработки сообщений делали. А из доп. потока в основной поток GUI приложения передавать данные через PostMessage или оповещать через это, так это много раз использовал, это по-моему удобно. Ну со службами тут другая история.

Вот-вот.

IT-Клоп [игнорируется] 
Один поток может подготавливать данные, потом "взводить" событие, а второй по событию их считывать и обрабатывать. Как одна из простых схем.

Просто Трёп [игнорируется] 
Если схема такая, что один пихает данные, а второй берет их и потом куда-то отправляет, то очередь можно использовать. Поток, который пихает, добавляет элементы в очередь. А который берет и что-то с ними делает, забирает из очереди по мере возможности, пока в очереди что-то есть.
Вот тут, если использовать не потокобезопасную очередь, можно как раз использовать критическую секцию. Первый поток входит в секцию, добавляет элемент, выходит, второй входит, забирает, выходит.

Просто Трёп [игнорируется] 

Очереди-то есть:
https://docwiki.embarcadero.com/Libraries/Alexandria/en/System.Generics.Collections.TQueue
https://docwiki.embarcadero.com/Libraries/Alexandria/en/System.Generics.Collections.TThreadedQueue
Я когда-то сам на основе динамического массива очередь делал. Но тут уже готовые. )

В программе есть долгий расчет, точнее - подбираются оптимальные параметры, длительность зависит от количества параметров. Максимальное - 4, считается долго, секунд 50 на одном тесте было. Три параметра - несколько секунд, 1-2 почти мгновенно. Более актуально 1-2-3. Но долгое время не так уж страшно, т.к. операция делается нечасто, находятся коэффициенты для калибровки, которой потом пользуются какое-то время, м.б. месяцы и т.п.

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

Попутно выяснил, читая обсуждения на стековерфлоу что не всё благополучно с этим TParallel.For в Delphi. Есть баг в последней версии, который можно попатчить самому или обойти некоторыми действиями. Судя по обсуждениям на стековерфлоу, не всё там и реализовано очень хорошо.
Но так, для инфы, есть в Delphi сейчас TTask, IFuture, TParallel.For и другие штуки, цель которых облегчить написание многопоточного или асинхронного кода.

TTask - Это класс, который позволяет выполнить передаваемую процедуру в фоновом потоке.