shared mutable state
+ multiple overlapping accesses
+ at least one write
+ missing ordering rule
= race condition candidate

읽기·수정·쓰기

Thread A reads count = 10
Thread B reads count = 10
Thread A writes 11
Thread B writes 11
expected 12, actual 11

count++는 source 한 줄이어도 read, add, write의 여러 단계가 될 수 있습니다. 실행 순서가 겹치면 update가 사라질 수 있습니다.

보호 범위

Lock은 가능한 한 짧게 유지하되 불변식을 반으로 자르지 않아야 합니다. 잔액 확인과 차감처럼 두 단계가 함께 성립해야 하면 둘을 같은 동기화 경계로 묶습니다.

공유 상태를 없애는 immutable data, message passing, thread confinement도 중요한 해법입니다. Lock을 추가하기 전에 누가 값을 소유하고 쓰는지 단순화할 수 있는지 봅니다.

자주 틀리는 점

• 실행에서 문제가 재현되지 않았다고 race가 없다고 판단하지 않습니다.
• collection 자체가 thread-safe여도 여러 호출을 묶은 조건은 별도 보호가 필요할 수 있습니다.
• 읽기만 한다고 항상 안전하지 않습니다. 다른 thread가 동시에 쓴다면 synchronization이 필요합니다.
• lock 안에서 느린 I/O나 외부 callback을 호출하면 대기와 deadlock 범위가 커집니다.