Hi
Во-первых, хочу по-приветствовать идею написания книги, выразить моральную поддержку и пожелать творческих успехов.

Во-вторых, позволь внести пару предложений.
В разделе 1.2. надо как-то более сжато выделить проблемы и требования к многопоточным приложениям. Что-то типа этого:
1. Библиотеки графических компонентов (как VCL так и FMX) способны корректно работать только в основном потоке, обращение к ним напрямую из любых других потоков недопустимо (как допустимо будет сказано ниже).
2. Обращение к данным внутри потока напрямую также недопустимо, так как в любой случайный момент времени данные могут быть еще полностью не сформированы, память не выделена, или уже уничтожена.
3. Многие не графические компоненты скрыто взаимодействуют между собой и графическим интерфейсом приводя к нарушениям требований 1 и 2. Например: TSQLConnection, TSQLDataSet, TDataSource и TDBEdit.
4. Требования из предыдущих пунктов ни как не контролируется средой разработки и требует особой внимательности разработчика. При этом ошибки носят вероятностный характер. Зачастую возможность появления ошибки зависит от скорости работы процессора, заполненности памяти, скорости работы сети и т.п.
5. Даже в случае правильной и безошибочной работы приложения не всегда возможна подлинная многозадачность. Например: выполнение длительных запросов в рамках одной сессий Oracle не может выполняться параллельно, т.е. запустив выполнение длительного запроса в отдельном потоке пользователь тем не менее всё равно не сможет полноценно работать с данными.

Когда вы собираетесь выносить часть кода в отдельный поток следует обратить внимание на следующие моменты:
1. Необходимо максимально сократить доступ к графическому интерфейсу, в идеале совсем исключить.
2. Необходимо максимально изолировать код внутри потока. Например: создаем модуль данных, подключаемся к БД, выполняем запрос, записываем результаты выполнения, разрушаем модуль данных.
3. Обязательно надо убедиться в потокозащищенности используемых в потоке компонентов. Причем декларируемая потокозащищенность не всегда соответствует действительности.
4. Следует убедиться в наличие достаточных человеческих ресурсов. Отладка будет на порядок сложнее, подумайте еще раз стоит ли игра свеч? Может целесообразней вынести долгое вычисление в отдельное приложение? Нужна ли действительно постоянная активность графического интерфейса, или достаточно простого окна ожидания?

Возможно стоит вынести код не в отдельный поток а в отдельное небольшое консольное приложение.

Для начинающих пример сложноват. Это скорее для второго тома. Многопоточное программирование для тех, кто бросает. 😁. Вообще на сайте не последняя версия. Последняя с исправлениями для 64 бит погибла вместе с винчестером. Когдато яя её кому-то выслал, может где и есть еще.

Я не знаю какая у тебя предметная область... у меня всякие клиент-серверные приложения, весьма крупные. И вот сколько бы контор не сменил почти во всех натыкался на решения " а не выполнить ли мне долгие запросы в отдельном потоке ". И использовать какраз компоненты имеющие проблемы в многопоточке и которые обращаются к графическому интерфейсу скрыто от глаз молодого бойца.
Описание проблемы в терминах тестировщика типа: " вот чето у нас всё работает, а у клиентов... у некоторых... иногда зависает в непонятных местах ".
Код хорошо характеризует высказывание одного патологоанатома:
В нашем морге последними словами 40% клиентов было "Гляди посоны как я могу!", а половина клиентов последнее что сказала "Не, дай я покажу как надо!".
Почти всегда исправление заключается в тупом переносе кода в основной поток. Прогрессбар можно перерисовать и repaint-ом, а обеспечивать реальную параллельную работу пользователя и так не требовалось.

А мне вот кажется что вычислительные задачи сводятся к "Получить данные из файла" -> "обработать" -> "сохранить результаты в файл". Вcё просто, ни каких межпроцессных обменов, для особых эстетов разве что процент выполнения можно прикрутить.

P.S. Я не призываю отказаться от тредов вообще и не надо меня убеждать в том что иногда они нужны. Я просто пытаюсь избавить от лишних проблем начинающих программеров и тех кто потом за ними будет код чистить.