Меня интересует вопрос по проведению следующего эксперимента(сейчас его возможности провести нет).
Есть 1000-а потоков, соединений с MSSQL. Эти соединения открыты на самом SQL сервере. На каждом из них готова уже конструкция и ждет команды execute. В управляющем потоке разыгрывается случайным образом очередь вызова, от 1 до 1000. Эта очередь записывается в лог(ЛогОчереди). Затем управляющий поток запускает все потоки на исполнение, предварительно запустив профайлер(трассы, расширенные события). Интересует в каких случаях очередь из лога будет расходиться с очередью вызова в профайлере, как часто это будет происходить?

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

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

Как раз гарантия старта не вполне контролируемая вещь. Например запуская с клиента вызов, из за долгого пинга у вас нет гарантий о времени его выполнения на сервере, и даже выполняя его на сервере в нагруженной многопоточной среде у вас также нет гарантий порядка выполнения. Впрочем проведите эксперимент и убедитесь.

Хотя пожалуй я придумал способ обеспечить порядок выполнения. Через проверку в бесконечном цикле уже понятно(определение номера последовательности и ожидания), еще подумаю как экономичней сделать через блокировки(пока не придумывается).

Пару мысленных экспериментов и экспериментов показали что решить задачу многопоточного воспроизведения один в один практически не возможно. Ну то есть в одном потоке все тривиально, но в многопоточной реализации даже если нет стайтментов и операции все примитивные типа I,U,D по первичному ключу, все равно дерево блокировок может отличаться. Время старта нельзя гарантировать не то что время завершения.
Тем не менее с некоторыми ограничениями задача решается. То есть можно переигрывать и откатывать. То есть можно проверять статус и в особо "узких" многопоточных запросах при проигрывании можно расставлять маркеры блокировки. А в некоторых случаях просто признавать определенных частях "трассы" что воспроизведение не приводит к повторяемым результатам.