Вы бы поискали совсем недавнее наше обсуждение подобной темы с Login, там я как раз давал пример запуска таймеров со смещением, но там нужна была некоторая точность, потому там именно таймеры. В Вашем случае не стоит путать потоки и ММ-таймеры (обычные таймеры вообще не наш случай, они не порождают отдельный поток и не так точны). Зарегистрированное на таймер событие (onTimer), действительно вызывается системой каждые, скажем, 15 мс, порождая новый поток. Если процессор одноядерный, то физически остальные потоки на этот момент прерываются.
Ваш же случай использует Thread, который не вызывается каждые 15 мс, а засыпает на 15 мс после выполнения каких-то задач. Это кардинальная разница. Например, если задача занимает целую секунду, то график работы будет 1сек_работы - 15мс_сна - 1сек_работы - 15мс_сна. Если потоков у Вас, скажем, два, и второй тоже выполняет что-то, требующее секунду на обработку, а процессор одноядерный либо многоядерный, но всё распределилось на одно ядро, то никто ему после 15мс сна управление не вернул бы и график должен был бы выглядеть так: 1_поток_1сек_работы - 2_поток_1сек_работы - 1_поток_1сек_работы. То есть Delay указывает минимум сна, максимум же теоретически не ограничен и определён работой соседних потоков. Однако на практике всё несколько сложнее, помимо встроенной в Thread задержки, система самостоятельно усыпляет потоки с определёнными интервалами, зависящими от их приоритета исполнения, загруженности ядер и т.п. и отдаёт управление другим. Эти интервалы могут быть не кратны ни Delay потока, ни времени исполнения обрабатываемой им итерации. При этом не забываем, что ещё и основной поток приложения хочет работать и ему тоже выделяется время, на которое все остальные усыпляются (опять же, если не работают в отдельном ядре процессора). Это я Вам ещё про прерывания решил не рассказывать
Как видите, задержка (Delay) - вещь условная, и на практике не должна быть основой для точных иили синхронизированных по времени задач. И должно быть понятно, для чего сделан SafeMode - регулярно прерывая потоки, система передаёт управление другим, и не дай бог это какое-нибудь чтение из стека, в который, например, наполовину не дописались данные из параллельного потока, а система приостановила запись и отдала управление потоку чтения.
И стек гарантированно наполняется медленнее, чем считываются данные из него Не будем забывать, что при использовании на ветке doPush SafeMode с WaitMode=Wait, вся она (ветка) подвисает (в прямом смысле, занимая максимум процессорного времени) на время работы ветки с doPop. Причём, не зависимо от того, что та, вторая ветка, делает. Даже если она уже прочла стек и выполняет остальные задачи, тот факт, что она начиналась через SafeMode автоматически блокирует запуск веток через SafeMode с теми же Name и Mode, пока ветка не завершится целиком (то есть дойдёт до элемента, к которому не подсоединены обработчики событий ни справа, ни по EventFromData - сверху).