[운영체제] 프로세스

Process (1)

🔊 이화여자대학교 반효경 교수님의 KOCW 2014년 1학기 운영체제 강의를 들으며 정리한 노트입니다.
      캡쳐한 이미지 중 따로 출처 명시를 하지 않은 이미지 또한 반효경 교수님 강의 자료에 있음을 밝힙니다.

프로세스의 개념

• “Process is a program in execution“
  (프로세스는 실행중인 프로그램을 말한다)
• 프로세스의 문맥(context)
  • CPU 수행 상태를 나타내는 하드웨어 문맥
    • Program Counter
    • 각종 register
  • 프로세스의 주소 공간
    • code, data, stack
  • 프로세스 관련 커널 자료 구조
    • PCB (Process Control Block)
    • Kernel stack

프로세스의 문맥이란 “프로세스가 어디까지 수행을 했는가, 어디까지 왔는가?” 즉, 프로세스의 현재 정확한 상태를 나타내는데 필요한 모든 요소이다.
이러한 일련의 정보를 가지고 있으면 프로세스가 현재 어떤 상태에 있는지를 정확하게 규명할 수 있게 되는 것이다.

프로세스의 상태 (Process State)

• 프로세스는 상태(state)가 변경되며 수행된다
  • Running
    • CPU를 잡고 instruction을 수행중인 상태
  • Ready
    • CPU를 기다리는 상태
      (메모리 등 다른 조건을 모두 만족하고 CPU를 주면 당장 instruction을 수행할 수 있는 상태)
  • Blocked (wait, sleep)
    • CPU를 주어도 당장 instruction을 수행할 수 없는 상태
    • Process 자신이 요청한 event(예: I/O)가 즉시 만족되지 않아 이를 기다리는 상태
    • ex) 디스크에서 file을 읽어와야 하는 경우
  • New: 프로세스가 생성중인 상태
  • Terminated: 수행(execution)이 끝난 상태
    (프로세스의 수행이 끝났지만 약간 정리할게 남아있는 상태)

프로세스 상태도

(컴퓨터 시스템 입장해서 알기쉽게 그려놓은) 프로세스의 상태 (저번이랑 같은 시스템 구조 그림이지만 메모리는 따로 그리지 않음)

프로세스들이 줄을 서서 기다리고 작업하는 모습
(뒤로 줄을 서면서 기다렸다가 작업 수행)

오래 기다리는 작업이 필요하면 프로세스는 blocked 상태가 되고, 그 오래 기다리는 작업이 공유데이터 때문인지, 디스크 때문인지, 키보드 때문인지 그 종류에 따라서 해당하는 I/O queue 혹은 Resource queue에 가서 줄 서있게 되고, 정말 그 작업이 완료가 되면 다시 Ready queue로 넘어와서 CPU를 얻을 수 있게 되는 것
(마치 놀이공원가서 줄서서 놀이기구 한번 타고 그 다음 다른 놀이기구가서 줄서서 타는 모양과 비슷)

이런식으로 운영을 해서 모든 자원들이 놀지 않고, 다 일을 잘 할 수 있게 해주는 매커니즘이 필요한 것이다.

사실은 이런 큐는 운영체제 커널이 본인의 데이터 영역에 자료구조로 큐를 만들어놓고 프로세스의 상태를 바꿔가면서 Ready 상태에 있는 애들 중에서 CPU를 주고, Blocked 상태에 있는 애들한테는 CPU를 안주고 이런식으로 운영하는 것이다

Process Control Block (PCB)

• 운영체제가 각 프로세스를 관리하기 위해 프로세스당 유지하는 정보
• PCB는 다음의 구성 요소를 가진다 (구조체로 유지)

• (1) OS가 관리상 사용하는 정보
  • Process state, Process ID
  • scheduling information, priority
  • (운영체제가 프로세스를 관리하기 위한 정보)
• (2) CPU 수행 관련 하드웨어 값
  • Program counter, registers
  • (프로세스의 문맥을 표시하기 위한 정보들)
• (3) 메모리 관련
  • code, data, stack의 위치 정보
• (4) 파일 관련
  • Open file descriptors…
  • (프로세스가 사용하고 있는 파일들이 어떠한건지…)
  • (그 외 리소스와 관련된 정보)

문맥 교환 (Context Switch)

• CPU를 한 프로세스에서 다른 프로세스로 넘겨주는 과정
• CPU가 다른 프로세스에게 넘어갈 때 운영체제는 다음을 수행
  • CPU를 내어주는 프로세스의 상태를 그 프로세스의 PCB에 저장
  • CPU를 새롭게 얻는 프로세스의 상태를 PCB에서 읽어옴

프로세스가 중간에 CPU를 중간에 빼앗겨야 되는 경우 그냥 지워버리는게 아니라 다음 CPU를 얻었을 때 정확하게 중단된 시점부터 실행을 재개하기 위해서 레지스터에 저장되어있던 값(Program counter 값, Memory map)을 그 해당 프로세스의 PCB에다 저장을 해놓는다.

이번에 CPU를 얻게 된 프로세스도 처음 실행되는게 아니라 과거에 얻었을 때 실행한 위치부터 재개하기 위해서 운영체제가 CPU를 넘겨줄 때 그 프로세스의 문맥을 PCB에서 찾아가지고 하드웨어에다가 복원을 다시 시키고, 그런 다음에 CPU를 다시 넘겨주게 되는 것이다.

• System call이나 Interrupt(하드웨어 인터럽트) 발생시 반드시 context switch가 일어나는 것은 아님

시스템 콜이나 인터럽트가 발생한 이후에 운영체제가 CPU를 다른 프로세스한테 넘겨주는 경우만 Context switch이다. → (2)

시스템 콜이나 인터럽트가 발생했는데 운영체제가 뭔가 처리를 하고, 발생하기 이전의 프로세스한테 CPU가 다시 넘어가면 그것은 Context switch가 아니다. → (1)

• ★ (1)의 경우에도 CPU 수행 정보 등 context의 일부를 PCB에 save해야 하지만 문맥교환을 하는 (2)의 경우 그 부담이 훨씬 큼 (eg. cache memory flush)

프로세스를 스케줄링 하기 위한 큐

• Job queue
  • (현재 시스템에 있는 모든 프로세스를 유지하고 있는 큐)
  • 현재 시스템 내에 있는 모든 프로세스의 집합
• Ready queue
  • (CPU를 기다리는 줄)
  • 현재 메모리 내에 있으면서 CPU를 잡아서 실행되기를 기다리는 프로세스의 집합
• Device queues
  • (각 I/O 디바이스마다 그 I/O 디바이스의 서비스를 기다리는 줄)
  • I/O device의 처리를 기다리는 프로세스의 집합
• 프로세스들은 각 큐들을 오가며 수행된다

Ready queue에 있거나 Device queue에 있는 프로세스가 Job queue에도 포함되있는 것이다.
그렇지만 Ready queue에 있으면 Device queue에 안들어있을 것이고,
Device queue에 있으면 Ready queue에 안들어있다.

Ready Queue와 다양한 Device Queue

실제 시스템에서 이런 Queue가 어떻게 관리 되는지를 보여주는 모습

디바이스마다 큐가 있고 queue header… head하고 tail 포인터를 가리키는 것들로 구성이 되어있고,
큐에 줄 세우는 것들은 (프로세스를 줄 세운다고 말했는데) 정확하게는 운영체제가 이 프로세스를 관리하는 자료구조인 PCB를 줄 세우는 것

아까 봤던 PCB 부분을 보면 PCB의 자료구조에서 pointer라고 있었다.
PCB들을 줄줄이 연결할 수 있는 pointer를 이용해서 연결을 해놓은 것이다.(위 그림 화살표)

이런식으로 프로세스들이 다양한 큐에 줄서서 서비스를 받게 되고, 운영체제가 이런 것을 관리하고 있는 것임

프로세스 스케줄링 큐의 모습

프로그램이 시작이 되면 먼저 ready queue에 와서 줄을 서게 되고 언젠가 자기 차례가 되면 CPU를 얻을 것이다.
CPU를 얻은 상황에서 본인이 CPU를 계속 쓰고 싶지만 할당의 시간이 끝나면(time slice expired) 다시 ready queue의 뒤에 와서 줄을 서야 되는 것이고,
또 CPU를 가지고 있다가 오래 걸리는 작업을 수행하면(I/O request) 그 해당하는 작업의 큐(I/O queue)에 가서 줄 서 있다가 그 작업이 끝나면(I/O) 다시 CPU를 얻을 수 있는 곳(ready queue)에 와서 줄 서게 되는 것이다.
이런식으로 뭔가 쭉 수행이 되다가(CPU) 본인의 본연의 역할이 다 끝났으면 이 프로세스는 종료가 되서 빠져 나가는 것이다.(CPU에서 오른쪽으로 나가는 화살표)

또는 프로세스가 CPU를 얻었는데 I/O가 아니라 인터럽트가 걸리면(wait for an interrupt) 인터럽트가 끝날 때까지 이 프로세스는 ready queue에 와서 줄 서는 것 처럼 그려놨다. → 사실 이 부분 그림은 잘못된 그림이다
인터럽트가 발생했을 때(wait for an interrupt) 이 프로세스가 CPU를 빼앗긴 것이기 때문에 ready 상태에 있는 것처럼 그려놨지만 정확하게는 ready 상태로 넘어가는 것이 아니다.

또, 프로세스가 CPU를 잡고있다가 자식 프로세스를 만들 수가 있다(fork a child).
(이것은 다음 챕터에 프로세스 생성과 관련된 설명을 할 때 나오는 내용이다)
자식 프로세스가 실행 중인 동안에(child executes) 본인은 CPU를 놓고 ready queue에 와서 줄 서서 기다리는 모습

스케줄러 (Scheduler)

시스템 안에서 스케줄러는 각각의 자원 별로 이번에 무슨 일을 하고, 다음에 무슨 일을 하고, 일을 하는 시간을 얼만큼씩 잡고 이런 것을 정하는 것이 스케줄러이다.(여기서 디스크 스케줄러에 대한 얘기는 안 나옴)

• Long-term scheduler(장기 스케줄러 or job scheduler)

  • 시작 프로세스 중 어떤 것들을 ready queue로 보낼지 결정

  • 프로세스에 memory(및 각종 자원)을 주는 문제

    (메모리를 어떤 프로세스한테 줄지를 결정하는 문제)
    (어떤 프로세스가 new 상태에 있는데, 걔한테 메모리를 줄지 안줄지 결정함)

  • degree of Multiprogramming을 제어

    (degree of Multiprogramming은 메모리에 프로그램이 몇 개 올라가 있는가를 나타내는 것)
    (즉, 메모리에 올라가 있는 프로세스의 수를 제어하는게 Long-term scheduler의 역할)
    (컴퓨터 시스템에서 메모리에 프로그램 몇 개를 동시에 올려놓을지를 제어하는 것은 굉장히 중요한 이슈이다)

  • time sharing system에는 보통 장기 스케줄러가 없음 (무조건 ready)

    (보통 우리가 사용하는 시스템에서는 장기 스케줄러가 없다는 얘기)
    (우리가 사용하는 시스템에서는 Medium-Term Scheduler를 이용해서 degree of Multiprogramming을 조절)
    (메모리에 너무 많은 프로그램들이 동시에 올라가 있으면 문제가 되기 때문에 중기 스케줄러를 두고 있는 것)

• Short-term scheduler(단기 스케줄러 or CPU scheduler)

  • 어떤 프로세스를 다음번에 running시킬지 결정
    (다음번에 어떤 프로세스한테 CPU를 줄지를 결정하는 것임)
  • 프로세스에 CPU를 주는 문제
  • 충분히 빨라야 함 (millisecond 단위)

• Medium-Term Scheduler(중기 스케줄러 or Swapper)

  • 여유 공간 마련을 위해 프로세스를 통째로 메모리에서 디스크로 쫓아냄
  • 프로세스에게서 memory를 뺏는 문제
  • degree of Multiprogramming을 제어
    (즉, 메모리에 올라가 있는 프로세스의 수를 조절, 전체적으로 시스템의 성능이 좋아지게 하는 것)

장기 스케줄러의 개념이 나왔을 때는 애초부터 메모리에 올라갈 수 있는 프로그램의 개수를 제어했었는데, 지금의 시스템은 장기 스케줄러가 없고 대신에, 중기 스케줄러가 있어서 일단 메모리에 다 올려놓고 너무 프로그램이 많이 메모리에 올라가 있다면 중기 스케줄러가 몇 개를 쫓아내는 것이다.
그렇게 해서 Multiprogramming degree를 조절하게 된다.

그렇기 때문에, 시스템 입장에서는 중기 스케줄러를 두는게 훨씬 더 효과적이다.

아까 프로세스의 상태 3가지에 중기 스케줄러때문에 상태가 추가된 것이 있다.
그 상태가 바로 아래에 추가되어 나올 Suspended 상태이다.

프로세스의 상태 (Process State)

• Running
  • CPU를 잡고 instruction을 수행중인 상태
• Ready
  • CPU를 기다리는 상태(메모리 등 다른 조건을 모두 만족하고)
• Blocked (wait, sleep)
  • I/O 등의 event를 (스스로) 기다리는 상태
  • (예) 디스크에서 file을 읽어와야 하는 경우
• Suspended (stopped)
  • 외부적인 이유로 프로세스의 수행이 정지된 상태
  • 프로세스는 통째로 디스크에 swap out 된다
    (메모리에서 다 쫓겨나서 프로세스가 디스크로 swap out된 상태를 말한다)
  • (예) 사용자가 프로그램을 일시정지 시킨 경우 (break key)
    시스템이 여러 이유로 프로세스를 잠시 중단시킴
    (메모리에 너무 많은 프로세스가 올라와 있을 때)
    
• ★ Blocked: 자신이 요청한 event가 만족되면 Ready
  (자신이 뭔가 요청한 일을 하면서 오래 기다리고 있는 상태)
  (자신이 요청한 I/O 작업이나 이런게 끝나면 다시 Ready 상태로 돌아갈 수가 있는 것)
• ★ Suspended: 외부에서 resume해 주어야 Active
  (외부에서 정지 시켜놓은 상태)
  (외부에서 다시 재개를 시켜줘야 다시 Running, Ready, Blocked 등의 Active한 상태로 넘어갈 수 있는 것)

Suspended를 제외한 세 가지 상태에서는 중기 스케줄러때문에 메모리를 통째로 빼앗긴 프로세스의 상태가 표현이 안된다.
메모리를 통째로 빼앗겼으면 CPU를 얻어도 아무 일도 못할텐데 그런 상태는 Running, Ready 도 Blocked도 아니다.
Blocked라는 것은 프로그램 본인이 CPU를 잡고 뭔가 일을 하다가 I/O 작업 같이 오래 걸리는 작업을 위해서 다른데가서 작업을 하고 있는 것이다.
(프로세스의 입장에서 보면 CPU든 I/O에서든 일을 하고, 적극적으로 CPU를 기다리고 있음)

Suspended상태는 CPU뿐만 아니라 외부(중기 스케줄러 혹은 사용자)에서 프로세스를 강제로 정지 시켜놓은 상태
외부의 주체가 중기 스케줄러라면 중기 스케줄러가 프로세스한테 메모리를 통째로 빼앗아 버리는 것, 그러면 하던 일을 멈추고 정지가 되버리는 것이다.

사용자가 프로세스(프로그램)를 일시 정지 시켰을 경우에도 프로세스는 메모리를 통째로 잃어버리고 Suspended 상태가 되는데, 사람이 그 프로세스를 재개시켜줘야지만 다시 Running, Ready, Blocked 등의 Active한 상태로 넘어갈 수 있다.

앞서 봤던 프로세스 상태도와 위치가 조금 바뀌었다.
그리고, Running을 두가지로 나눠서 그려놨다.
프로세스가 CPU를 가지고 있으면서 본인의 코드를 실행중인 상태 → user mode의 Running
본인이 어떤 일을 할 수 없어서 운영체제한테 대신 요청하는 즉, 시스템 콜을 하게 되어 운영체제의 코드가 실행 중인 상태 → Running(monitor mode), 커널 모드에서 Running하고 있다고 부름(운영체제가 Running하고 있다고 부르지 않는다! 매우 유의 할 부분)
또한, 인터럽트나 이러한 것들이 들어왔을 때 사용자 프로그램이 실행되다가 운영체제의 커널의 코드가(인터럽트 서비스 루틴이) 실행된다. 이 인터럽트는 프로그램 때문에 실행되는 것이 아니라 외부의 어떤 다른 요인때문에 인터럽트가 들어왔겠지만 그래도 이 상황에서 보통은 이 프로그램이 여전히 Running하고 있다고 간주한다. 다만 커널 모드(모니터 모드)에서 러닝하고 있다고 부른다.

그래서, 여기 있는 그림은 전부 사용자 프로그램의 상태도를 나타내는 것이다.
그래서 시스템 콜이나 인터럽트가 끝났으면 다시 user mode에서 사용자 프로그램의 코드를 실행할 것이다. 이 두 개의 개념을 나눠 놓았다.

(Suspended를 추가한)프로세스 상태도

거기에 Suspended 상태가 추가 된 것이다.
Suspended도 Blocked 상태에서 Suspended가 되었느냐, Ready 상태에서 Suspended가 되었느냐에 따라서 나누어 표현을 하고,

점선의 아랫 부분은 외부적인 이유로 프로세스가 완전히 얼어붙어서 정지 되있는 상태이고, inactive라 부른다.
외부에서 프로세스를 정지 시켰으면 다시 외부에서 재개를 해줘야지만 점선 위로 올라갈 수가 있다.
점선 위는 CPU를 얻었거나, CPU를 기다리거나, I/O를 하는 등 열심히 작업을 하고 있는 상태

그럼에도 불구하고, Suspended Blocked에서는 I/O 같은 오래 걸리는 작업이 실행이 되면 Suspended Ready로 바뀔 수는 있다.
Suspended 상태에서도 진행이 가능하다는 얘기…
Suspended라는 것은 기본적으로 메모리를 완전히 잃어버리는(Swap out되는) 상황이기 때문에 CPU 관점에서 아무 일을 할 수가 없지만, I/O 같은 작업이 진행중이었다고 하면 그것은 계속 진행이 되서 Suspended Ready로는 넘어갈 수 있다. 이 정도로 알아두면 되겠다.

---

Process (2), (3)

Thread

보통 프로세스가 하나 주어지면 그 프로세스만의 code, data, stack으로 구성된 주소공간이 만들어진다고 했었고, 그리고 이 프로세스를 관리하기 위해서 운영체제 내부에 PCB라는 것을 두고 있다고 했다. 이런 PCB에서 현재 메모리에 어느 부분을 실행하고 있는지를 program counter가 가리키고 있다.

우리가 동일한 일을 하는 프로세스가 여러개 있다고 하면 그것을 별도의 프로세스로 만들면 이러한 메모리 주소공간이 여러개가 만들어질 것이다. 그렇다면, 프로세스마다 별도의 주소 공간이 만들어져서 메모리가 낭비가 될 것이다.
그렇기 때문에, 같은 일을 하는 프로세스를 여러개 띄워놓고 싶다고 한다면 주소공간(메모리 공간)은 하나만 띄워놓고, 현재 각 프로세스마다 다른 부분의 코드를 실행할 수 있게 해주면 될 것이다.
그것이 Thread(쓰레드)의 개념이다.

쓰레드라는 것은 code, data, stack… 프로세스는 하나만 띄워놓는다. 그리고, 현재 CPU가 코드의 어느 부분을 실행하고 있는가 보여주는 program counter만 여러개를 두는 것이다.

즉, 프로세스 하나에 CPU 수행 단위만 여러개 두고 있는 것을 Thread(쓰레드)라고 부른다.

위 이미지를 보면 알 수 있듯이 각 쓰레드(CPU 수행 단위)마다 현재 register에 어떤 값을 넣고, program counter가 코드 어느 부분을 가리키면서 실행하고 있었는가를 별도로 유지하고 있다.
그리고, Thread라는 것은 프로세스 하나에서 공유할 수 있는 것은 최대한 공유하고(메모리 주소 공간, process state, 프로세스가 사용하는 각종 자원들 등을 쓰레드끼리는 공유하고 있다.),
다만, 별도로 가지고 있는 것은 CPU 수행과 관련된 정보(program counter, register, stack 등의…)이다.

• “A thread (or lightweight process) is a basic unit of CPU utilization”
  (쓰레드는 CPU를 수행하는 단위이다)
• Thread의 구성 (쓰레드간에 독립적으로 가지고 있는 것들)
  • program counter
  • register set
  • stack space
• Thread가 동료 thread와 공유하는 부분(=task)
  • code section
  • data section
  • OS resources
• 전통적인 개념의 heavyweight process는 하나의 thread를 가지고 있는 task로 볼 수 있다

Thread들끼리 공유하는 부분을 다른 말로 task라고 부른다.
즉, 하나의 프로세스 안에는 쓰레드가 여러개 있으면 task는 한개만 있는 이런 구조가 된다.

쓰레드를 lightweight process라고도 부른다. process를 별도로 두는 것보다 process안에 쓰레드를 여러개 두는 것이 훨씬 더 가볍기 때문에…
프로세스를 쓰레드로 관리하게 되면 쓰레드를 lightweight process라고 부르는 것이다.
반대로 그렇지 않고, 전통적인 프로세스는 heavyweight process라고 부른다.

Thread를 사용하면 어떤 장점이 있는가?

• 다중 스레드로 구성된 태스크 구조에서는 하나의 서버 스레드가 blocked (waiting) 상태인 동안에도 동일한 태스크 내의 다른 스레드가 실행(running)되어 빠른 처리를 할 수 있다.(사용자에게 빠른 응답성 제공)
• 동일한 일을 수행하는 다중 스레드가 협력하여 높은 처리율(throughput)과 성능 향상을 얻을 수 있다.
• 스레드를 사용하면 병렬성을 높일 수 있다.
  (CPU가 여러개 달린 컴퓨터에서만 얻을 수 있는 장점)

프로세스는 하나기 때문에 PCB는 하나만 만들어진다.
프로세스 안에 쓰레드가 여러개 있게 되면 CPU 수행과 관련된 정보만 각각 쓰레드마다 별도로 가지고 있게 된다.(program counter, register 정보)

쓰레드의 장점을 위에서 대강 설명을 했지만, 쓰레드를 사용하는 장점은 크게 4가지로 요약을 해볼 수 있다.

요약

• Responsiveness(응답성)
  (사용자 입장에서 빠른 것)

  • eg) multi-threaded Web
    - if one thread is blocked (eg network)
    another thread continues (eg display)

    (먼저 HTML문서를 갖고온 다음 그 안에 있는 이미지 파일을 다시 웹 서버한테 요청을 하게 된다. 요청을 한 순간에 원래는 프로세스가 block이 된다.

    웹 프로그램이 쓰레드를 여러개 가지고 있으면, 네트워크 요청을 한 그 쓰레드만 block이 된다.
    그러면 이때, 다른 쓰레드가 이미 읽어온 HTML 문서라도 화면에 먼저 띄워주게 되면 사용자 입장에서는 텍스트라도 먼저 나오니 답답함이 덜할 것이다.)
    (이것도 일종의 비동기식 입출력)

• Resource Sharing(자원을 공유)

  • n threads can share binary code, data, resource of the process

    (만약, 똑같은 일을 하는 프로그램이 여러개 있는데 그것을 별도의 프로세스로 사용하는 것보다는 하나의 프로세스를 만들고 그 안에 CPU 수행 단위만 여러개를 두게 되면 code, data 그리고 각종 자원은 쓰레드들이 공유를 하게 됨)

    (그러면, 자원을 효율적으로 쓰는 효과를 얻을 수 있다.)

• Economy(좀 더 빠르다(응답성하고는 약간 다른 의미))

  • creating & CPU switching thread (rather than a process)

    (프로세스를 하나 만드는 것은 overhead가 상당히 크다. 프로세스 하나 안에다가 쓰레드를 하나 추가하는 것은 숟가락만 하나 얹으면 되는 것이기 때문에 overhead가 그리 크지 않다.)
    (context switch(문맥 교환)가 일어날 때 하나의 프로세스로부터 또다른 프로세스로 CPU가 넘어가므로 overhead가 상당히 크다.
    프로세스 내부에서 쓰레드 간의 CPU Switch가 일어나는 것은 대단히 간단하다. 동일한 주소 공간을 쓰고 있기 때문에 대부분의 문맥은 그대로 사용할 수가 있으므로…)

    (그래서, 프로세스 하나를 생성하고 CPU를 스위치 하는 것보다, 쓰레드 하나를 생성하고 CPU 스위치 하는게 훨씬 overhead가 적음)

  • Solaris의 경우 위 두 가지 overhead가 각각 30배, 5배

    (Solaris 운영체제의 경우 쓰레드를 생성하는 것보다 프로세스 하나를 생성하는 overhead가 30배가 더 든다.
    CPU Switch가 일어날 때 쓰레드 하나를 스위치하는 것보다 프로세스를 context switch하는 overhead가 5배가 더 들게된다는 얘기)

    (그러니 가능하면 같은 일을 하는 작업인 경우 프로세스를 여러개 만드는 것보다, 프로세스 안에 쓰레드를 두는 것이 훨씬 효율적이다!)

• Utilization of MP Architectures

  (CPU가 여러개있는 Multi Processor 아키텍쳐인 경우)
  (CPU가 여러개 있는 환경에서 쓰레드를 뒀을 때 얻을 수 있는 장점)

  • each thread may be running in parallel on a different processor

    (각각의 쓰레드가 서로 다른 CPU에서 병렬적으로 일을 할 수 있다.)
    (그러면, 결과를 더 빨리 얻을 수 있는 장점이 있다.)

맨 위 세 가지는 CPU가 하나 있는 환경에서도 적용가능한 일반적인 얘기
마지막 부분은 이와 다른 특별한 경우

Implementation of Threads(쓰레드를 구현할 수 있는 방법)

• Some are supported by kernel → Kernel Threads
  • Windows 95/98/NT
  • Solaris
  • Digital UNIX, Mach
• Others are supported by library → User Threads
  • POSIX Pthreads
  • Mach C-threads
  • Solaris threads
• Some are real-time threads

어떤 쓰레드는 운영체제 커널의 지원을 받고 있고,
또 다른 쓰레드 구현 방식은 라이브러리 형태로 구현을 하고 있다.
그 각각을 커널 쓰레드, 유저 쓰레드라고 부름

(여기 나와있는 시스템들 최근에 새로운 시스템들의 인터페이스가 나오면서 조금씩 의미가 섞여있지만 개념만 간단히 설명…)
커널 쓰레드는 쓰레드가 여러개 있다는 사실을 운영체제 커널이 알고 있다.
그래서, 하나의 쓰레드에서 다른 쓰레드로 CPU가 넘어가는 것도 커널이 CPU 스케줄링 하듯이 넘겨주게 된다.

유저 쓰레드는 프로세스 안에 쓰레드가 여러개 있다는 사실을 운영체제는 모름.
유저 프로그램이 라이브러리의 지원을 받아서 스스로 여러개의 쓰레드를 관리함
어떻게 보면 커널이 모르고 있고, 커널이 볼 때는 일반적인 프로세스로 보이는데 프로세스 본인이 내부에서 CPU 수행 단위를 여러개 두면서 관리를 하는 것이기 때문에 약간의 구현상의 제약점들은 있을 수 있다.

개념적으로만 알아두기!
커널의 지원을 받아서 커널이 쓰레드의 존재를 알면 커널 쓰레드
커널의 지원을 받지않고, 사용자 수준에서 쓰레드를 구현하게 되면 유저레벨 쓰레드
리얼 타임 기능을 지원하는 리얼 타임 쓰레드도 생성을 할 수 있다.

맨 위로 이동하기