Process

http://www.kocw.net/home/search/kemView.do?kemId=1046323 

KOCW 반효경 교수님의 운영 체제 강의를 수강하면서 작성한 포스트입니다. 😁

 

프로세스

"Process is a program in execution" 

현재 시점의 정확한 상태를 규명하기 위해서 필요한 요소들을 문맥이라 할 수 있습니다. 

프로세스의 문맥은 크게 3가지로 볼 수 있습니다.

 

* CPU 수행 상태를 나타내는 하드웨어 문맥 (Program counter, 각종 register)

* 프로세스의 주소 공간 (code, data, stack)

* 프로세스 관련 커널 자료 구조(PCB, Kernel stack)

 

프로세스의 상태 (Process state)

프로세스는 상태(state)가 변경되며 수행되게 됩니다. 

 

Running

CPU를 잡고 instruction을 수행중인 상태

 

Ready

메모리 등 다른 조건을 모두 만족하고 CPU를 기다리는 상태

 

Blocked (wait, sleep)

CPU를 주어도 당장 instruction을 수행할 수 없는 상태

Process 자신이 요청한 이벤트가 즉시 만족되지 않아서 이를 기다리는 상태

 

Suspended (stopped)

외부적인 이유로 프로세스의 수행이 정지된 상태

프로세스는 통째로 디스크에 swap out 됨

(ex. 사용자가 프로그램을 일시 정지 시킨 경우, 시스템이 여러 이유로 프로세스를 잠시 중단 시킴)

 

Blocked vs. Suspended: Blocked는 자신이 요청한 event가 만족되면 ready 상태로 변경되고, suspended는 외부에서 resume 해줘야 active로 상태가 변경됩니다.

 

크게 이렇게 프로세스의 상태를 구분지을 수 있고, 경우에 따라서는 다음과 같은 상태들을 추가해서 생각합니다.

 

New: 프로세스가 생성 중인 상태

Terminated: 수행이 끝난 상태

 

 

Process Control Block (PCB)

PCB는 운영체제가 각 프로세스를 관리하기 위해 프로세스당 유지하는 정보를 말합니다. PCB는 구조체 형태로 다음의 요소들을 가집니다.

* OS가 사용하는 정보 (Process state, Process ID, scheduling information, priority)

* CPU 수행 관련 하드웨어 값 (Program counter, registers)

* 메모리 관련 (code, data, stack의 위치 정보)

* 파일 관련 (open file descriptors...)

 

문맥 교환 (Context Switch)

CPU를 한 프로세스에서 다른 프로세스로 넘겨주는 과정을 문맥 교환, context switching이라고 합니다.

CPU가 다른 프로세스에게 넘어갈 때 운영체제는 다음을 수행하게 됩니다.

* CPU를 내어주는 프로세스의 상태를 그 프로세스의 PCB에 저장

* CPU를 새롭게 얻는 프로세스의 상태를 PCB에서 읽어 옴

 

 

System call이나 Interupt가 발생 시 반드시 context switching이 일어나는 것은 아닙니다.

(1)의 경우에도 CPU 수행 정보 등 context의 일부를 PCB에 save해야 하지만, 문맥 교환을 하는 (2)의 경우에는 그 부담이 훨씬 큽니다.

(1)의 경우는 Process A에서 커널 모드로 들어갔다가 다시 Process A가 실행되는 것을 볼 수 있습니다. 이런 경우는 context switching이라고 하지 않습니다. 커널 모드 진입 후 다른 프로세스를 실행시키는 (2)의 경우가 context switching이 발생했다고 말할 수 있습니다.

 

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

Job queue

현재 시스템 내에 있는 모든 프로세스의 집합

 

Ready queue

현재 메모리 내에 있으면서 CPU를 잡아서 실행되기를 기다리는 프로세스의 집합

 

Device queue

I/O device의 처리를 기다리는 프로세스의 집합

 

스케줄러 (Scheduler)

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

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

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

* degree of Multiprogramming을 제어 (메모리에 올라가 있는 프로세스의 수를 제어)

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

 

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

* 어떤 프로세스를 다음번에 running 시킬 지 결정

* 프로세스에 CPU를 주는 문제

* 충분히 빨라야 함 (millisecond 단위)

 

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

* 여유 공간 마련을 위해 프로세스를 통째로 메모리에서 디스크로 쫓아냄

* 프로세스에게서 memory를 뺏는 문제

* degree of Multiprogramming을 제어

 

요즘의 OS 들은 time sharing system을 사용하고 있기 때문에, Long-term scheduler 보다는 Medium-Term scheduler를 이용해서 degree of Multiprogrmming을 제어하고 있습니다. Medium-Term scheduler를 통해 프로세스를 메모리에서 디스크로 쫓아낼 경우 이 프로세스의 상태는 suspended로 변경됩니다.

 

 

Thread

"A thread (or lightweight process) is a basic unit of CPU utilization"

프로세스 내부에 CPU 수행 단위가 여러 개가 있는 경우 스레드라고 부르게 됩니다.

같은 일을 하는 프로세스를 여러 개 띄우게 되면, 프로세스가 낭비되겠죠. 그래서 스레드라는 개념이 나오게 되었습니다.

이처럼 프로세스 하나에 CPU 수행 단위만 여러 개 띄우는 것을 스레드라고 합니다. code, data 영역은 공통으로 사용하고, stack은 각각의 스레드가 따로 갖습니다. 공유할 수 있는 부분은 최대한 공유하고, CPU 사용과 관련된 정보들만 따로 갖게 됩니다. (PC, registers, stack)

 

Thread의 구성

* program counter

* register set

* stack space

 

Thread가 동료 Thread와 공유하는 부분 (=task)

* code section

* data section

* OS resources

 

다중 스레드로 구성된 태스크 구조에서는 하나의 서버 스레드가 blocked (waiting) 상태인 동안에도 동일한 태스크 내의 다른 스레드가 실행(running)되어 빠른 처리를 할 수 있습니다. 동일한 일을 수행하는 다중 스레드가 협력하면 높은 처리율(throughput)과 성능 향상을 얻을 수 있습니다. 또한 스레드를 사용하게 되면 병렬성을 높일 수 있습니다.

 

Benefits of Threads

* Responsiveness

* Resource Sharing

* Economy

* Utilization of MP Architecture