Two-Phase Locking 2PL: Protocol, Phases, and a Worked Example | AI Research

Two-Phase Locking (2PL): Protocol, Phases, and a Worked Example

Verified Sources

Sep 24, 2026

Two-Phase Locking {keywordkeywordkeywordkeywordkeywordkeywordkeyword.

Core idea: Each transaction follows a strict workflow:

Growing phase: acquire locks (read/write locks) as needed; no lock is released.
Shrinking phase: release locks; no new locks are acquired.

This structure prevents a transaction from “first reading/writing safely, then later changing its mind” by acquiring additional locks after it has started releasing, which is a key reason 2PL yields correct ordering. The protocol is widely used because it is simple to enforce and guarantees schedules are conflict-serializable for standard (non-upgrade) 2PL variants.

Two-Phase Locking (2PL) Explained

Why S-locks and X-locks matter

A transaction must hold an S-lock before performing a read.
A transaction must hold an X-lock before performing a write.
Compatibility: multiple S-locks on the same item can coexist, but any X-lock conflicts with both S- and X-locks from other transactions.

[CalloutBlock] type: "tip" title: "Pro Tip" content: "When working examples, write each transaction’s lock actions (S/X + acquire/release) next to each read/write. The moment a transaction releases its first lock, it must stop acquiring any new locks."

Applying 2PL to a simple schedule (worked example)

1
Step 1
Let T1 and T2 operate on data items X and Y. Use the standard lock rule: reads require S-locks; writes require X-locks.
2
Step 2
Assume T1 does: r1(X); w1(Y). Under 2PL it must acquire S-lock on X before r1(X), and acquire X-lock on Y before w1(Y).
3
Step 3
Assume T2 does: r2(Y); w2(X). It must acquire S-lock on Y before r2(Y), and acquire X-lock on X before w2(X).
4
Step 4
A valid schedule is: T1 acquires S(X), T2 acquires S(Y), then each tries to write the other’s item, causing waiting until the conflicting lock is released—while each transaction respects growing-then-shrinking.
5
Step 5
Once T1 releases its first lock, it enters shrinking and cannot acquire more locks. Similarly for T2.
6
Step 6
Verify that the resulting order of conflicting read/write operations corresponds to some serial execution (e.g., T1 then T2 or T2 then T1).

Concrete example schedule (with waits)

Consider two transactions:

T1: $r_1(X)$ ; $w_1(Y)$
T2: $r_2(Y)$ ; $w_2(X)$

Assume the following interleaving (a 2PL-style schedule):

Time	Transaction	Action
1	T1	Acquire S-lock on $X$
2	T1	$r_1(X)$
3	T2	Acquire S-lock on $Y$
4	T2	$r_2(Y)$
5	T1	Request X-lock on $Y$ (conflicts with T2’s S-lock) → wait
6	T2	Request X-lock on $X$ (conflicts with T1’s S-lock) → wait

This particular interleaving can lead to deadlock (both waiting for the other to release). The important point for 2PL explanation is how the protocol constrains lock behavior:

Both T1 and T2 have acquired locks but none has released yet, so both are still in the growing phase.
If a transaction were to release a lock to resolve waiting, it would enter the shrinking phase and must stop acquiring additional locks afterward.

To make the example fully “progressive,” consider an alternative schedule that avoids deadlock by releasing before attempting a conflicting write:

Deadlock-free 2PL schedule variant

Time	Transaction	Action
1	T1	Acquire S-lock on $X$
2	T1	$r_1(X)$
3	T1	Release S-lock on $X$ (T1 now in shrinking phase)
4	T2	Acquire S-lock on $Y$
5	T2	$r_2(Y)$
6	T2	Acquire X-lock on $X$ (if free)
7	T2	$w_2(X)$
8	T2	Acquire X-lock on $Y$ (if no longer held by T1; otherwise wait)
9	T2	$w_2(Y)$
10	T2	Release locks; commit
11	T1	(No new lock acquisitions allowed after step 3, so T1 cannot attempt $w_1(Y)$ if it would require a new X-lock held later)

What this shows: once T1 releases its first lock, 2PL forbids further lock acquisitions; therefore, if T1 still needs an X-lock on $Y$ for $w_1(Y)$ , it must have acquired it earlier (during growing). That’s precisely the “two-phase” constraint.

A cleaner didactic example (shows both phases clearly)

Let the transactions be:

T1: $r_1(X)$ ; $r_1(Y)$ ; $w_1(X)$
T2: $w_2(Y)$ ; $r_2(X)$

A 2PL-compliant schedule:

Time	Transaction	Action
1	T1	Acquire S-lock on $X$ ; $r_1(X)$
2	T1	Acquire S-lock on $Y$ ; $r_1(Y)$
3	T1	Acquire X-lock on $X$ (upgrade-like behavior or X-lock initially; assume allowed by the chosen 2PL variant) ; $w_1(X)$
4	T1	Release locks on $X$ and $Y$ (shrinking phase)
5	T2	Acquire X-lock on $Y$ ; $w_2(Y)$
6	T2	Acquire S-lock on $X$ ; $r_2(X)$
7	T2	Release locks; commit

Because T1 releases and stops acquiring before T2 begins conflicting work, the conflicts line up with a serial order: T1 then T2.

[CalloutBlock] type: "warning" title: "Warning" content: "If you release a lock too early in 2PL, you may be unable to perform later reads/writes that require additional locks—because acquiring after releasing is prohibited by the protocol."

2PL lifecycle (for one transaction)

Acquire locks

Phase 1: Growing

Acquire S/X locks for every data item you will access."

First release

Growing ends

The first time you release any lock, you switch to shrinking."

Release locks only

Phase 2: Shrinking

You may release remaining locks but must not acquire new ones."

Common exam pitfalls

Lock actions across phases (per item)

Illustrative: acquiring stops once releasing begins.

2PL Quick Checks

1 / 4

Question · Term

Growing phase rule

Click to reveal

Answer · Definition

You may acquire S/X locks, but you may not release any lock.

Knowledge Check

Question 1 of 4

Q1Single choice

In two-phase locking, once a transaction releases any lock, it is no longer allowed to...

Acquire any new locks

Release more locks

Perform reads that require no locks

Commit immediately

Explore Related Topics

Deadlock Avoidance and Resource-Allocation Graphs with Cycles but No Deadlock

Deadlock avoidance grants resources only when the resulting state is safe, using safety tests (e.g., the Banker’s algorithm) and graph analysis to prevent unsafe allocations.

A request is granted iff the post‑allocation state satisfies a safe sequence:  $\text{Grant request} \iff \text{state is safe}$ .
In a single‑instance resource graph, any cycle means deadlock; with multiple instances, a cycle only indicates a possible deadlock.
The safety test checks for a process $P_i$ with $Need_i \le Available$ ; such a process can finish, release resources, and repeat the check.
Example: $R_1$ (1 instance) and $R_2$ (2 instances) form a cycle, but $P_3$ can complete and break it, so no deadlock occurs.
The OS may defer a request even when resources are free if granting it would move the system to an unsafe state.

Reader–Writer Problem and Semaphore-Based Process Synchronization

Paging with Translation Lookaside Buffer (TLB) Scheme

Browse all research articles