Concurrency Control in Jetpack Compose

In computer science, a concurrency control system is responsible for making sure a system behaves correctly when multiple operations happen at the same time.

It is about coordination and synchronization. The rules of concurrency control exist to keep the system safe and correct, even when multiple parts run in parallel. But this coordination comes at a cost, often impacting performance. The challenge is to design something safe but also efficient.

A classic example is the transaction system used in database management systems (DBMS). There, concurrency control ensures that multiple transactions can run at the same time without corrupting the data. This means:

• Transactions are atomic
• Changes can be safely reverted
• Committed data is never lost
• Aborted changes do not leave side effects

This is not limited to databases. Concurrency control is also used in programming languages, including how Compose manages state through snapshots.

Jetpack Compose uses a simplified form of transactional memory, which lets a group of state reads and writes behave like an atomic unit.

In Compose, state writes from a snapshot are applied as a single atomic operation. This means:

• The snapshot groups changes together
• Those changes are either fully applied or not at all
• Updates across threads stay consistent

Atomic changes can also be aborted, reverted, or reproduced. This opens the door to having a form of version history. That helps in reproducing past versions of the state or discarding unsafe changes.

There are different categories of concurrency control systems, each with its own performance and safety trade-offs.

1. Optimistic:

Do not block reads or writes. Assume things will be fine. If something would break on commit, abort the transaction and retry. This works best when the rate of conflicts is low.

2. Pessimistic:

Block any operation that might break the rules, until it's safe to proceed. This avoids errors but reduces performance.

3. Semi-optimistic:

A hybrid. Block some operations, stay optimistic for others.

Each type performs differently depending on the system's needs. Pessimistic systems are more prone to deadlocks, which are usually resolved by aborting one of the stalled operations and restarting it.

Jetpack Compose uses an optimistic concurrency control system.

When multiple Composables update shared state at the same time, Compose lets those changes go through. At the end, during state propagation, Compose checks for collisions.

If it detects a conflict, it will try to automatically merge the changes. If merging fails, the changes are aborted. This strategy works well for UI because conflicts are rare, and retrying is usually cheap.

Unlike database transactions, Compose snapshots do not need to be recoverable, durable, distributed, or replicated. They are simple, fast, in-memory, and in-process only. Still, they are atomic, consistent, and isolated. That is enough for a reactive UI system.

Jetpack Compose implements its state snapshot system using a concurrency control model called Multiversion Concurrency Control (MVCC).

This is the same approach used by high-performance databases. MVCC improves concurrency by creating a new version of an object every time it is written. It also allows the system to read from multiple recent versions.

Why MVCC?

Jetpack Compose allows Composables to run concurrently, which means threads might be reading or writing state at the same time. That makes isolation necessary.

One of the core properties of concurrency control systems is isolation. A basic way to achieve isolation is to block reads until writes are finished. But this hurts performance.

MVCC solves this better.

To isolate state access, Compose uses snapshots. Each thread works with an isolated snapshot of the state at a specific moment. You can think of each snapshot as a version of the state.

Modifications done inside a snapshot are invisible to others until they are fully complete and pushed forward.

This is known as snapshot isolation, a concurrency pattern where each transaction (snapshot) sees a consistent view of the system.

In Compose, MVCC works hand in hand with immutability. When data is written, a new copy is made. This results in multiple versions of the same object existing in memory. Compose calls these state records. We'll go deeper into state records in a future post.

Compose also creates point-in-time consistent views of state. This means all data within a snapshot stays coherent.

Each snapshot is assigned a unique ID. These IDs are monotonically increasing, so they are always ordered. This ordering is key for deciding which snapshot version to read from or write to.

With snapshot IDs, Compose can isolate reads and writes without using locks. It keeps performance high while ensuring state safety.

Concurrency is one of the hardest problems in software. But Jetpack Compose solves it in a way that is elegant, fast, and built for real UI needs.

Let's recap:

• Jetpack Compose uses an optimistic concurrency control system
• State changes are grouped in snapshots
• Each write is atomic and creates a new version
• Snapshots are isolated from one another using MVCC
• Snapshot IDs help maintain a consistent point-in-time view
• This entire system is built to support safe parallel recomposition

You don't need to manage any of this manually, but knowing how it works helps you build better, faster, and safer Compose UIs.