futex wait가 timeout이나 signal로 돌아왔습니다. 반환 뒤 lock word를 다시 검사해야 하는 이유는 무엇인가요?

futex wait가 반환됐다는 것은 커널 대기 상태가 끝났다는 뜻이지 lock ownership을 얻었다는 뜻이 아닙니다. 정상 wake, timeout, signal에 따른 EINTR처럼 반환 원인이 무엇이든 현재 futex word와 상위 predicate를 다시 확인하고, 실제 성공은 CAS가 소유 상태를 만든 시점에만 판정합니다. raw futex와 libc wrapper가 timeout·signal을 어떤 errno로 매핑하는지는 사용 중인 kernel/ABI와 source를 확인해야 하므로, 이 답변은 그 정책을 확인한 뒤의 상위 lock 루프를 설명합니다.

deadline=10ms인 B가 t=0에 wait를 시작해 t=9ms에 signal을 받았다고 하겠습니다. word가 1이면 B는 남은 1ms를 기준으로 다시 기다리거나 취소를 반환해야 합니다. word가 0이면 CAS를 먼저 시도할 수 있지만, CAS 실패 뒤 다른 owner가 생기면 다시 predicate를 평가합니다. signal 때마다 새 10ms를 주면 반복 signal로 전체 대기가 무한히 늘어나므로 monotonic absolute deadline에서 remaining=deadline-now를 계산합니다. timeout 직후 unlock이 있었더라도 API가 timeout 우선인지 마지막 획득 기회를 허용하는지는 호출자 계약으로 고정합니다.

wake도 경쟁적입니다. B가 깨어난 사이 C가 먼저 CAS를 성공하면 B는 임계 구역에 들어가지 않고 word를 재검사합니다. 객체를 파괴할 때도 WAKE 한 번은 waiter의 syscall과 callback 완료를 보장하는 barrier가 아니므로, 새 대기를 막고 waiter 종료를 확인한 뒤 word와 관련 메모리를 해제합니다. 이 문항은 “반환=성공”이라는 오류를 교정하는 데 초점을 두며, 구체적인 EINTR/ETIMEDOUT 명칭은 Linux man-pages와 libc source를 함께 확인한 결과로만 기록하겠습니다.