Order Execution Engine

Environment

Everything below was measured on 2026-07-19 by re-running the committed Release binaries at one commit. Numbers are specific to this machine and toolchain.

Architecture

Trading signals flow through a multi-stage pipeline, with the concurrency boundary drawn where it matters and each lock justified in the code:

• Signal Evaluator filters by confidence and generates orders in parallel on a thread pool.
• Orders cross a lock-free SPSC queue to the routing thread. It uses std::atomic acquire/release ordering (not sequential consistency, which is a full fence on x86) because the producer/consumer relationship is one-directional. Head and tail sit on separate cache lines (alignas(64)) so the two cores do not bounce a shared line.
• A semaphore-based Rate Limiter models exchange message throttling.
• The Order Book does price-time-priority matching, generating fills. Cancellation uses an index for expected O(1) price-level lookup, then a linear scan within that level's FIFO order storage.
• The Position Book updates from fills under a shared_mutex (concurrent reads, exclusive writes).
• The MPMC queue (used under contention) uses Dmitry Vyukov's per-slot sequence-number design; monotonic sequence numbers make stale CAS attempts fail safely, which is the ABA guard.
• Deadlock prevention is by a total lock order (OrderBook = 1, PositionBook = 2), always acquired ascending, which breaks the circular-wait condition. A debug-mode DeadlockDetector validates it at runtime and compiles to zero-cost no-ops in Release (#ifndef NDEBUG).

Performance

Latency and throughput are two separate binaries, two separate experiments. I keep them apart.

Order-to-fill latency

bench_latency: 100,000 market buy orders against 1,000 resting sell limit orders (reseeded every 100), 4 engine threads. Each order is timed with std::chrono::high_resolution_clock from submit until its fill is drained by a tight spin. Percentiles are nearest-rank over recorded fills. About 99% of orders filled immediately (99,000 and 98,998 of 100,000 across two runs); percentiles are over those fills.

The millisecond max is the tail from the ~1% of orders that did not fill immediately and sat on the poll path. It is real, so I show it; p50 and p99 are over filled orders.

Queue throughput

bench_queue_throughput: 10,000,000 ops per configuration, 16-byte items, wall time by high_resolution_clock, one timed run per invocation. I ran the binary three times for variance.

SPSC throughput is ~93 to 105M ops/sec, median ~103M. MPMC throughput drops as producers and consumers contend on the shared ring, which is the expected shape.

Correctness

Separate from performance, and fully reproduced.

The runtime deadlock detector is debug-only, so its violation-injection sub-test is skipped in the Release run.

Portability and race detection (Linux / Clang)

Scoped to portability and correctness, not performance. WSL2 virtualization is fine for detecting races; I do not use it for latency or throughput claims.

• Commit 1514743 reproduced the Windows/MSVC results but did not compile on Clang 18. Three MSVC-permissive constructs: a missing <mutex> include, an in-class default argument relying on a nested struct's default member initializers, and std::result_of deprecation warnings from std::bind.
• Fixed in commit 381d19a, after which the engine built and passed 11 of 11 under Clang 18 Release on Ubuntu 24.04.
• A Clang ThreadSanitizer run then exposed a lost-wakeup deadlock in thread-pool shutdown. The shutdown condition was updated outside the condition variable's mutex, so a worker could miss the notification and sleep indefinitely. MSVC timing masked it; TSan's scheduling hit it reliably. I fixed the mutex discipline, added a shutdown regression test (1,000 construct/shutdown iterations, run under an external timeout), and reran the MSVC, Clang Release, and TSan suites.

Clang ThreadSanitizer reported no data races across the exercised unit and concurrency stress suites on Ubuntu 24.04 under WSL2, commit 499b60e: 11 of 11 tests, the 100P/100C MPMC and 10M-item SPSC stress, the 50-thread deadlock torture, and the shutdown regression run 20 times. ThreadSanitizer did not emit a deadlock report; the instrumented run changed scheduling enough to expose the hang.

Reproduction

From the engine package, at the stated commit:

cmake .. -G "Visual Studio 17 2022" -A x64
cmake --build . --config Release
ctest -C Release --output-on-failure
./Release/bench_queue_throughput
./Release/bench_latency
./Release/stress_queue
./Release/stress_deadlock

Expected throughput output (abridged):

| Queue Type | Config | Ops/sec  | Wall Time |
| SPSC       | 1P:1C  |  102.7M  |    97ms   |
| MPMC       | 1P:1C  |   79.7M  |   125ms   |
| MPMC       | 4P:4C  |   12.9M  |   775ms   |
| MPMC       | 8P:8C  |   10.5M  |   950ms   |

Expected stress output (abridged):

[STRESS] MPMC Queue: 100P/100C, 1000000 items
  Result: PASS (1000000/1000000 consumed)
[STRESS] Lock ordering (50 threads, 50000 ops): PASS - 0 violations

Limitations

• Single machine, in-memory only. No network or kernel-bypass NIC, so this is pipeline latency, not wire-to-wire.
• Synthetic workload: uniform market orders against a dense resting book. Real flow is burstier and adversarial.
• Built with security-hardening flags (/GS /guard:cf), not max-speed flags, and no -march=native. A -O3 Linux/Clang build would likely be faster.
• The ~1% of orders that do not fill immediately inflate the p99.9 and max tail through the poll path.
• All numbers are specific to the i5-12600K / Windows / MSVC environment above. Different hardware or toolchain will differ.

A note on older numbers

An earlier version of this site quoted a higher SPSC throughput, a tighter p99, and a bare "ThreadSanitizer clean" label. Those probably came from a Linux/Clang build, but I could not recover the original output or environment, so I removed them rather than present numbers without a complete evidence chain. If I reproduce them on Linux I will publish both sets side by side as a cross-toolchain comparison, not as a rescue of the old headline.