빠르게 얻지 못한 잠금은 대기 경로로 넘깁니다

이 코드는 어떤 문제를 푸나요?

mutex는 공유 객체를 한 번에 한 실행 흐름만 수정하도록 보호합니다. 다른 태스크가 이미 가지고 있으면 기다리며 잠들 수 있으므로 호출 문맥이 중요합니다. 이 짧은 진입 함수에서도 문맥 검사, 빠른 획득, 느린 대기 경로를 구분할 수 있습니다.

읽을 범위: v6.18.37 · kernel/locking/mutex.c · mutex_lock 269–275행입니다. 이 본문은 CONFIG_PREEMPT_RT=n 및 CONFIG_DEBUG_LOCK_ALLOC=n 분기에서 정의됩니다. 아래에 이 범위의 원문과 각 줄의 설명을 실었습니다. 주제 전체의 흐름과 다른 경로는 기존 분석에서 함께 읽으실 수 있습니다.

먼저 알아둘 개념

소유권

한 태스크가 보호 구역에 들어갈 권리를 갖는 상태입니다.

빠른 경로와 느린 경로

경쟁이 없으면 작은 원자 연산으로 끝내고, 경쟁 시에는 대기자 관리와 스케줄링이 필요한 경로로 갑니다.

처음 읽을 때

코드를 읽을 때 might_sleep로 잠들 수 있는 곳인지 확인합니다. 그다음 어느 상태가 바뀌는지 각 줄에서 확인하세요.

더 깊이 살펴볼 때

이 경로의 호출 문맥, 잠금·인터럽트 상태, 오류 시 남는 자원을 함께 추적해 보세요. 호출된 함수가 수행하는 작업과 현재 함수가 직접 보장하는 범위를 구분하는 것이 중요합니다.

그림으로 보는 변화

전체 흐름1단계 · 멈춰 보기2단계 · 멈춰 보기3단계 · 멈춰 보기

1단계 고정

1. 문맥 검사

might_sleep로 잠들 수 있는 곳인지 확인합니다.

검사는 잠금을 획득한 것과 다릅니다.

2. 빠른 획득

owner 전체 값이 0일 때만 원자적 비교·교환으로 잠금을 얻습니다.

실패한 경우에만 다음 대기 경로로 갑니다.

3. 대기 경로

경쟁을 처리하고 소유권을 얻은 뒤 반환합니다.

반환 뒤에는 호출자가 잠금을 해제할 책임이 있습니다.

mutex_lock를 한 줄씩 읽기

줄 번호는 v6.18.37 원문 기준입니다. 주석·빈 줄을 포함한 함수 전체를 먼저 보고, 그 아래에서 각 줄을 설명합니다.

void __sched mutex_lock(struct mutex *lock)
{
	might_sleep();

	if (!__mutex_trylock_fast(lock))
		__mutex_lock_slowpath(lock);
}

void __sched mutex_lock(struct mutex *lock)

	might_sleep();

	if (!__mutex_trylock_fast(lock))

		__mutex_lock_slowpath(lock);

함께 생각해 볼 질문

출처와 읽은 범위

Linux stable v6.18.37 · kernel/locking/mutex.c

해당 버전 원본 파일 · 기존 코드 분석 · 설명 원고