SeqLock

by Stan Drapkin

A high-performance, optimistic reader-writer synchronization primitive for .NET that enables lock-free, consistent snapshots of compound state in read-heavy scenarios.

What is SeqLock?

SeqLock (sequence lock) is a reader-optimized synchronization primitive designed for scenarios where reads are much more frequent than writes. It allows multiple readers to access shared data concurrently without blocking, even in the presence of concurrent writers.

Instead of blocking readers when a writer is active, SeqLock readers run optimistically and without locking. Writers mark the shared state as "in-progress" using a version counter, update the state, then mark it as "stable" again. Readers detect writer interference by checking the version before and after reading, and simply retry on interference.

• Writers serialize
• Readers never block, and retry instead of blocking on interference

Why use SeqLock?

Traditional reader–writer locks (ex. ReaderWriterLockSlim) provide strong consistency guarantees: a reader always sees a fully consistent view of shared state. To achieve this, every reader must participate in lock coordination via atomic operations and memory fences.

This has 2 consequences:

1. Every read has non-trivial overhead, even when no writers interfere.
2. Read scalability degrades as the number of readers increases.

SeqLock exists to solve a different problem:

How to make reads as cheap, fast and scalable as possible when writers are rare and brief?<br> ...while still providing strong external consistency?

By removing reader-side locking entirely, SeqLock reduces the read path to:

Version check #1 → Fast data read → Version check #2

If no writes interfere (the common case), the reads complete with no blocking and minimal synchronization cost.

How SeqLock differs from ReaderWriterLockSlim?

The key difference is optimistic vs pessimistic synchronization:

• ReaderWriterLockSlim prevents inconsistency
  • Readers block writers (or vice versa)