futex 대기 직전에 다른 스레드가 lock을 풀었습니다. FUTEX_WAIT가 기대값을 함께 받는 이유와 EAGAIN 처리는 무엇인가요?

FUTEX_WAIT(address, expected)는 주소만 보고 무조건 잠드는 호출이 아니라, 현재 word가 expected와 같을 때만 compare-and-block을 진행하는 호출입니다. B가 word=1을 읽어 expected=1을 준비한 뒤 A가 unlock하여 word=0으로 바꾸고 wake했다고 하겠습니다. B가 단순 WAIT(address)를 했다면 wake가 waiter 등록 전에 지나가 영원히 잠드는 경합이 생길 수 있습니다. expected 비교가 대기 진입과 연결되면 B가 커널에 들어온 시점의 word=0을 발견해 block하지 않고 불일치 경로로 돌아가므로, Linux/glibc 경로에서 흔히 EAGAIN으로 처리하는 재시도가 가능합니다. raw syscall의 errno 이름은 사용한 ABI와 wrapper에서 확인합니다.

시간순 trace는 B read 1 → A store 0 → A WAKE → B WAIT(expected=1) → value mismatch/EAGAIN 경로 → B CAS(0,1)입니다. EAGAIN은 lock 알고리즘 전체의 치명적 실패가 아니라 “기다릴 조건이 이미 사라졌다”는 재시도 신호입니다. 반대로 word가 여전히 1이면 B가 대기열에 들어갈 수 있습니다. wake 호출 수와 wait 호출 수가 일치해야 한다는 뜻도 아닙니다. wake는 상태를 저장하는 토큰이 아니라 predicate를 다시 확인할 기회입니다.

정상 wake 뒤에도 C가 먼저 CAS를 성공할 수 있으므로 B는 항상 word를 다시 읽고 CAS 또는 상위 predicate를 평가합니다. 반환 정책은 raw futex, libc wrapper, mutex 구현의 오류 매핑을 구분해야 하며, EINTR와 timeout까지 같은 while 루프에서 다룰 때 deadline을 유지합니다. 이 질문은 missed wakeup을 피하는 비교 계약에 초점을 두고, 사용자 공간 fast path의 비용이나 pthread 내부 레이아웃을 섞지 않겠습니다. 확인할 때는 unlock 선행, 두 waiter 동시 wake, 객체 lifetime을 각각 재현 표로 분리합니다.