Concurrency Control 1: Locking

Advanced Topics in Computer Systems	Fall 2001
Joe Hellerstein & Anthony Joseph

Concurrency Control 1: Multi-Granularity Locking

Some implementation background (not in reading):

Locks vs. Latches

locks assure logical (i.e. xactional) consistency of data. They are implemented via a lock table, held for a long time (e.g. 2PL), and part of the deadlock detection mechanism.
latches are like semaphores. They assure physical consistency of data and resources, which are not visible at the transactional level (e.g. latch a frame in a buffer pool). They are not subject to 2PL (usually held for a very short time), and the deadlock detector doesn't know about them (and therefore...?).
Acquiring a latch is much cheaper than acquiring a lock (10s vs. 100s of instructions in the no-conflict case)

latch control info is always in VM in a fixed place
lock tables are dynamically managed (can have a lock per tuple!), so data structure mgmt on lock/release is more complex

Lock table is a hashed main-mem structure
Lock/Unlock must be atomic operations (protected by latches or critical sections)
typically costs several hundred instructions to lock/unlock an item
Lock Upgrades

suppose T1 has an S lock on P, T2 is waiting to get X lock on P, and now T3 wants S lock on P. Do we grant T3 an S lock?

No! (starvation, unfair, etc.) So...

Manage FCFS queue for each locked object with outstanding requests
all xacts that are adjacent and compatible are a compatible group
The front group is the granted group
group mode is most restrictive mode amongst group members

Conversions: often want to convert (e.g. S to X for "test and modify" actions). Should conversions go to back of queue?
No! Instant deadlock. So put conversions right after granted group.

More on deadlocks below

More notes for the curious...

We will read more in a couple weeks about non-2PL locking schemes, and the consistency guarantees they provide
Most DBMSs have multiple lock request types, in part to help with that. E.g. DB2 has:

conditional vs. unconditional lock requests (are you willing to wait?)
instant vs. manual vs. commit duration lock requests (wait, but plan to hold for different amounts of time)

Gray, et al.: Granularity of Locks

Theme: Correctness and performance

Granularity tradeoff: small granularity (e.g. field of a tuple) means high concurrency but high overhead. Large granularity (e.g. file) means low overhead but low concurrency.
Possible granularities:

DB
Areas
Files
Pages
Tuples (records)
fields of tuples

Want hierarchical locking, to allow "large" xacts to set large locks, "small" xacts to set small locks
Problem: T1 S-locks a record in a file, then T2 X-locks the whole file. How can T2 discover that T1 has locked the record?
Solution: "Intention" locks

	NL	IS	IX	S	SIX	X
NL
IS
IX
S
SIX
X

IS and IX locks
T1 obtains S lock on record in question, but first gets IS lock on file.
Now T2 cannot get X lock on file
However, T3 can get IS or S lock on file (the reason for distinguishing IS and IX: if there were only I, T3 couldn’t get an S lock on file)
For higher concurrency, one more mode: SIX. Intuitively, you read all of the object but only lock some subparts. Allows concurrent IS locks (IX alone would not). Note: gives S access, so disallows IX to others.
requires that xacts lock items root to leaf in the hierarchy, unlock leaf to root
generalization to DAG of resources: X locks all paths to a node, S locks at least one.

Notes on Deadlock

In OS world, deadlock usually due to errors or overloads
In DB/xact world with 2PL, they’re inherent.
Most common causes:

Differing access orders

T2: X-lock Q

T1: X-lock Q // block waiting for T2

T2: X-lock P // block waiting for T1

lock-mode upgrades

T2: S-lock P

T1: convert S-lock on P to X-lock // block

T2: convert S-lock on P to X-lock // block

Usual DB solution: deadlock detection (other option: deadlock avoidance)

Use "waits-for" graph and look for cycles
Abort/restart some transaction along the cycle
Empirically, in actual systems the waits-for graph shows:

cycles fairly rare
cycle length usually 2, sometimes 3, virtually never >3
use DFS to find cycles

When to look for cycles?

whenever a xact blocks
periodically
never (use timeouts)

Typically, in centralized systems, run deadlock detection whenever blocking occurs. Arguably this is cheap: most recently blocked transaction T must be the one that caused the deadlock, so just DFS starting from T

In distributed systems, even this can be expensive, so often do periodic detection (more later)

Who to restart ("victim selection")

current blocker
youngest XACT
least resources used
fewest locks held (common)
fewest number of restarts