요약

스레드를 누가 관리하느냐에 따라 두 방식이 있다. 사용자 수준 스레드는 프로그램 안의 라이브러리가 관리하고, 커널은 스레드가 있는 줄도 모른다. 반장이 조원들 순서를 알아서 정하고 선생님은 조 단위로만 보는 셈이다. 커널을 거치지 않으니 스레드를 바꾸는 일이 빠르다. 하지만 한 스레드가 커널에 막히면 커널은 프로세스 전체를 멈추고, 프로세서가 여럿이어도 한 프로세스의 스레드를 나눠 싣지 못한다. 커널 수준 스레드는 그 반대다.

예시로 보기

프로세스 B에 스레드 1, 2가 있고, 사용자 수준 스레드 라이브러리가 이 둘을 관리한다. 커널은 B만 안다. 지금 스레드 2가 실행 중이다(그림 4.7a).

장면 스레드 라이브러리가 보는 상태 커널이 보는 B의 상태
(a) 처음 스레드 1 준비, 스레드 2 실행 실행
(b) 스레드 2가 입출력 같은 시스템 호출을 해서 커널이 B를 막음 스레드 1 준비, 스레드 2 여전히 실행 대기
(c) 대신 시계 인터럽트로 B의 시간 조각이 끝남 스레드 1 준비, 스레드 2 여전히 실행 준비
(d) 대신 스레드 2가 스레드 1의 결과를 기다려야 함. 라이브러리가 스레드 1로 바꿈 스레드 1 실행, 스레드 2 대기 실행

(b)가 핵심이다. 스레드 1은 실행할 준비가 되어 있는데도, 커널이 프로세스 B 전체를 대기시켰으므로 실행되지 못한다. (b)와 (c)에서 라이브러리 기록상 스레드 2가 “실행”인 것은, 실제로 프로세서를 잡고 있다는 뜻이 아니라 B가 다시 프로세서를 받으면 스레드 2부터 이어 간다는 뜻이다1.

정확히 말하면

  사용자 수준 스레드 (ULT) 커널 수준 스레드 (KLT)
누가 관리하나 응용 프로그램(스레드 라이브러리)이 모든 스레드 관리를 한다. 커널은 스레드를 모른다 커널이 프로세스 전체와 각 스레드의 문맥을 관리한다. 응용 프로그램은 스레드 관리를 하지 않는다
커널의 스케줄링 단위 프로세스 스레드
같은 프로세스 안 스레드 전환 커널 모드로 가지 않는다2 커널로 모드 전환이 필요하다. 이것이 KLT의 단점이다
한 스레드가 막히면 프로세스 전체가 막힌다 (위 표 b)2 커널이 같은 프로세스의 다른 스레드를 실행할 수 있다
프로세서가 여럿이면 한 프로세스의 스레드들이 동시에 여러 프로세서를 쓰지 못한다2 같은 프로세스의 여러 스레드를 여러 프로세서에 동시에 배정할 수 있다
그 밖에 스레드 스케줄링 방식을 응용에 맞게 고를 수 있다. 어느 운영체제에서나 라이브러리만 있으면 돈다2 커널 자신의 루틴도 다중 스레드로 짤 수 있다
예 스레드 라이브러리 Windows

KLT는 커널 지원 스레드, 경량 프로세스(lightweight process)라고도 부른다.

결합 방식. 스레드는 사용자 공간에서 만들고, 스케줄링과 동기화의 대부분도 응용 프로그램이 한다. 그러면서 여러 사용자 수준 스레드를 그보다 적거나 같은 수의 커널 수준 스레드에 대응시킨다. 잘 설계하면 같은 응용의 여러 스레드가 여러 프로세서에서 동시에 돌고, 막히는 시스템 호출이 프로세스 전체를 막지 않는다. 두 방식의 장점을 합치고 단점을 줄인다. Solaris가 예다.

Solaris는 스레드 관련 개념을 네 가지로 나눈다.

개념 뜻
프로세스 사용자 주소 공간, 스택, 프로세스 제어 블록
사용자 수준 스레드 프로세스 안의 스레드 라이브러리로 만든 실행 단위. 운영체제에 보이지 않는다
경량 프로세스 (LWP) 사용자 수준 스레드와 커널 스레드를 잇는 다리. LWP 하나는 커널 스레드 하나에 대응한다. 커널이 따로 스케줄링하고, 여러 프로세서에서 동시에 돌 수 있다
커널 스레드 프로세서에 배정되어 실행되는 기본 단위 
flowchart LR
  subgraph PR["프로세스, 사용자 공간"]
    U1["사용자 수준 스레드 1"]
    U2["사용자 수준 스레드 2"]
    U3["사용자 수준 스레드 3"]
    LIB["스레드 라이브러리"]
  end
  U1 --> LIB
  U2 --> LIB
  U3 --> LIB
  LIB --> L1["LWP 1"]
  LIB --> L2["LWP 2"]
  L1 --> K1["커널 스레드 1"]
  L2 --> K2["커널 스레드 2"]
  K1 --> C1["프로세서 1"]
  K2 --> C2["프로세서 2"]

왼쪽의 사용자 수준 스레드 셋은 커널에 보이지 않는다. 라이브러리가 이들을 LWP 둘에 나눠 싣고, LWP마다 커널 스레드가 하나씩 붙어 서로 다른 프로세서에서 동시에 돌 수 있다3.

스레드와 프로세스의 수 관계

표 4.2는 “스레드 : 프로세스”의 수 관계로 시스템을 나눈다.

스레드 : 프로세스 뜻 예
1 : 1 실행 흐름마다 자기 주소 공간과 자원을 가진 프로세스 전통적인 UNIX
M : 1 프로세스 하나가 주소 공간과 자원을 정하고, 그 안에 스레드 여러 개 Windows NT, Solaris, Linux, OS/2, OS/390, MACH
1 : M 스레드 하나가 여러 프로세스 환경을 옮겨 다닌다. 여러 시스템 사이를 쉽게 이동 Ra (Clouds), Emerald
M : N M : 1과 1 : M을 합친 것 TRIX

활용

  • 지금 많이 쓰는 운영체제(Windows, Linux)는 커널이 스레드를 직접 안다. 그래서 한 스레드가 디스크를 기다려도 같은 프로그램의 다른 스레드는 계속 돈다.
  • 프로세서가 여럿인 컴퓨터에서 한 프로그램이 모든 코어를 쓰려면 커널이 스레드를 알아야 한다 → 대칭형 다중 처리

연결

자주 하는 오해

“표 4.2의 M : 1은 사용자 수준 스레드 여러 개를 커널 스레드 하나에 대응시키는 다대일 모델이다”

틀렸다. 다른 교재(예: Silberschatz)의 “다대일 모델”은 사용자 스레드와 커널 스레드의 대응을 말한다. 표 4.2의 M : 1은 스레드와 프로세스의 수 관계로, “프로세스 하나에 스레드 여러 개”라는 뜻일 뿐이다. 그래서 커널 수준 스레드를 쓰는 Windows NT와 Linux가 M : 1 칸에 들어 있다. 무엇과 무엇의 비율인지 먼저 확인한다4.

확인 문제

C1 그림 4.7 상황 (a)에서 스레드 2가 파일 읽기 시스템 호출을 해서 커널이 막았다. 스레드 1, 스레드 2, 프로세스 B의 상태를 각각 쓰라. (ULT)

답: 스레드 1 준비, 스레드 2 실행(라이브러리 기록상), 프로세스 B 대기.
흔한 오답: 스레드 2를 대기로 적는 것. 커널은 스레드를 모르고 B만 막는다. 스레드 라이브러리는 이 일을 모르므로 스레드 2의 기록을 바꾸지 않는다.

C2 다음 상황에 ULT와 KLT 중 무엇이 유리한가? ① 프로세서 8개에서 한 프로그램의 계산을 나눠 빨리 끝내고 싶다. ② 스레드를 아주 자주 바꾸며, 막히는 시스템 호출은 거의 없다.

답: ① KLT. 커널이 스레드를 알아야 여러 프로세서에 나눠 줄 수 있다. ② ULT. 스레드 전환에 커널 모드 전환이 필요 없어 빠르고, ULT의 약점(막히는 호출이 프로세스 전체를 막음)이 거의 드러나지 않는다.

C3 KLT에서 같은 프로세스 안의 스레드를 바꿀 때도 모드 전환이 필요한 이유는?

답: 스레드의 문맥과 스케줄링을 커널이 관리하기 때문이다. 다음에 어느 스레드를 실행할지 정하고 문맥을 바꾸는 코드가 커널 안에 있으므로, 그 코드를 실행하려면 커널 모드로 들어가야 한다.

  1. 그림 4.7의 네 장면 설명은 그림을 글로 옮긴 것이다. 장면별 원인(시스템 호출, 시계 인터럽트, 스레드 1 기다림)과 “실행” 기록의 뜻은 Stallings, Operating Systems: Internals and Design Principles 6판, 4.2절의 그림 설명을 따랐다. ↩

  2. ULT 쪽 칸은 같은 교재 4.2절의 ULT 장단점(모드 전환 없음, 응용별 스케줄링, 어느 운영체제에서나 실행 / 막히는 호출이 프로세스 전체를 막음, 다중 프로세서를 쓰지 못함)으로 채웠다. ↩ ↩2 ↩3 ↩4

  3. 스레드 3개, LWP 2개라는 수는 보기를 위해 고른 값이다. ↩

  4. Silberschatz, Galvin & Gagne, Operating System Concepts, 4장 “다중 스레딩 모델”. ↩