OS(3) - Process

os수업을 들으며 본인이 정리한 내용입니다.

사용교재 : Operationg System Concepts 10th edition (공룡책)

 

3단원 : processes

 

process: 현재 수행중인 프로그램 (=job = task)

process != program

process는 수행되기 위해 메모리로 로딩이 되어야 한다. -> 메모리에 process address space라는 virtual 공간을 가진다.

<process가 process address space에 가지는 것들>

- stack : local변수, parameters

- heap : 동적으로 할당된 메모리

- data : local이 아닌 변수

- text : code

- PCB : process의 정보를 담고 있는 data structure

- program counter (PC)

- processor registers

program은 passive하고, process는 active하다. -> ex)함수를 call하면 stack증가, 메모리 할당할때마다 heap증가, pc가 가리키는 code가 계속 바뀜, state가 계속 바뀜

 

process의 state

- new : process 생성

- running : CPU가 process 수행중인 상태

- waiting : 이벤트 등을 기다리는 상태 (waiting상태에서는 CPU를 할당 받아서 수행할 수 없다)

- ready : processer가 다른 process를 수행중인 상태

- terminated : process가 끝남

OS마다 state의 분류는 다 다를 수 있음

 

PCB(process control block)

process에 연관된 정보들을 알 수 있음

- process 상태

- program counter(PC)

- CPU register

- CPU scheduling 정보

- memory관리 정보-> process address space 주소, address translation

- accounting 정보

- I/O 상태 정보

- …

Linux는 task_struct에 PCB의 모든 정보가 들어있음

 

process scheduling

scheduling이 중요한 이유: multitasking 때문-> 여러 task들을 담을 수 있는 queue가 필요

- job queue : 모든 process

- ready queue : ready 상태의 process

- device queue : device로부터 I/O를 기다리는 process

scheduler는 queue안에서 task들을 고른다.

선택 받은 task는 CPU로 dispatched된다

 

process는 scheduling을 잘 하기 위해 두 분류로 나눈다.

1. I/O-bound process : 연산량이 많지 않은 프로세서, 연산보다 입출력에 더 많은 시간 소요 (word)

2. CPU-bound process : 연산량이 많은 프로세서, 입출력 요청을 드물게 발생 (S/W codec)

 

CPU-intensive: CPU연산을 길게 수행하고, I/O연산은 짧게 수행함

IO-intensive: CPU연산과 I/O연산을 번갈아서 수행함

CPU는 IO-intensive에 우선순위를 준다 -> 보다 많은 process의 waiting time을 줄이기 위해서

 

scheduler

1. long-term scheduler

- 매우 가끔 수행됨 (infrequently)

- 새로운 프로세스를 accept할 것인지 결정 -> 거의 모든 프로세스를 올림

- degree of multiprogramming(process의 개수)을 제어-> system 안정성 결정

- 요즘의 UNIX와 Windows는 long-term scheduler가 없음 -> 모든 process를 메모리에 올림

2. short-term scheduler

- 우리가 흔히 이야기하는 스케쥴러

- ready queue에서 task를 선택함

- 매우 자주 수행됨 (frequently)

3. medium-term scheduler

- 중간 정도의 term

- 모든 task를 메모리에 올릴 수 없으므로 swap out할 task를 결정

 

context switch

process의 전환

- 기존에 수행되던 문맥을 해당 task의 PCB에 저장한다. (load)

- 새로 수행할 프로세스의 문맥(context)을 해당 task의 PCB에서 가져온다. (store)

- 많은 연산을 수행해야 하므로 시간이 오래 걸릴 수 있다. -> big overhead

- useful한 일을 하지는 않는다. -> 줄이는 것이 중요하다.

• SUN UltraSPARC -> multiple sets of registers : set이 여러 개 있어서, A가 1에 있으면 B는 2로 가면 됨
• ARM -> multiple store and load instructions : 여러 개의 register에 한번에 load하여 load 횟수를 줄임

 

process에 행해지는 operation

- process creation -> fork()

- process termination -> exit()

- Unix계열의 OS는 process들이 tree형태로 관리된다. (부모가 자식을 생성하는 구조)

- fork()를 호출한 process가 부모, 호출된 process가 자식이다.

- tree형태에서의 issue

1. 자식은 부모의 resource를 일부만 공유한다. (부모에 의해 open 된 파일만)

2. 부모와 자식은 concurrently 수행된다. 부모는 자식이 terminates될 때까지 기다린다.

3. 자식은 부모의 address space를 처음에는 duplication한다, 그 후 exec()함수로 자신만의 새로운 program을 load한다.

 

UNIX와 Linux에서 fork system call

- resource sharing: 부모와 자식 간에 file들은 공유, CPU와 memory는 공유가 안된다. -> 독립적으로 수행되어야 하기 때문

- execution(실행) : 부모와 자식은 concurrently 수행한다.

- address space : 독립된 address space가 필요하다. -> 별도로 수행되는 객체이기 때문, exac() 함수 필요

- call once, return twice : 처음에는 부모와 자식의 address space가 같다.

    -> return twice : 서로의 코드가 같기 때문에 return 값을 가지고 서로의 코드를 구분한다. (return을 두 번 한다는 이야기가 아님) 이때, return 값이 자식의 PID(process ID)이면 부모, 0이면 자식으로 구분한다.

- 과정

• child에서 exac system call이 호출되어 새로운 program을 load하고, stack과 heap을 초기화 한다.
• 부모는 wait함수를 호출하여 child함수가 termination되기를 기다린다.

cf) 부모에 wait함수가 없는데 child함수가 termination되었을 경우-> 부모가 자식을 거두지 않은 상태 ->  child함수가 좀비 state로 있게 됨

 

process termination

- 마지막에 exit함수를 호출함으로써 termination된다.

- process의 resource들이 해제된다.

- child함수가 termination 될 때, exit의 인자로써 wait 함수를 호출한 부모에게 메시지를 전달할 수 있다.

- abort함수 : exit함수는 자발적으로 termination되는 반면에 abort함수는 부모가 자식을 termination 시키는 함수이다.

   -> 자식함수가 필요없을 때 사용할 수 있다.

- cascading termination : 자식 프로세스를 termination시킬 때, 자식프로세스의 자식프로세스들까지 전부 termination 시킨다.

- 만약 부모를 잃게 되면 orphan process(고아 프로세스)가 된다.

- orphan process : 부모 프로세스가 termination된 process (tree구조의 링크가 끊어짐) -> 일반적으로 orphan process는 init process의 자식으로 맺어준다.

 

copy-on-write(COW)

- duplication은 overhead가 크기 때문에 나온 기법이다.

- address space를 duplication하지 않고, 부모 address space를 공유해서 쓰다가 자신의 address space를 바로 생성하는 방법이다. (write할 때 copy한다)

 

inter-process communication (IPC)

- independent process : process 간의 communication이 필요하지 않다.
- cooperating process : 서로 간의 영향을 받기 때문에 process 간의 communication이 필요하다. -> IPC 필요

process cooperation의 장점

• 정보 공유
• 병렬적으로 수행하기 때문에 계산 가속화
• modularity : 서로 모듈화해서 별도의 프로그램을 수행 할 수 있음
• convenience: 여러 개의 일을 한번에 수행 가능 ex)editing, printing, compiling at once.

 

IPC의 방법 2가지

1. message passing : kernel에 mail box생성하고 mail box를 통해 communication한다.

2. shared memory : 특정 프로세스의 특정 영역을 공유 영역으로 설정하여 다른 프로세스가 쓸 수 있도록 한다..

 

IPC가 필요한 경우

- producer consumer problem : 데이터를 생성하는 producer process와 데이터를 소비하는 consumer process간에 IPC가 필요하다. -> 중간에 생성한 데이터를 넣어 놓는 buffer가 있어야 하기 때문, buffer공간은 shared memory에 존재한다.

   cf) bounded-buffer : 버퍼의 크기 고정 / unbounded-buffer : 버퍼의 크기에 한계 없음

- 소비할 데이터가 없을 때 consumer는 waiting한다. -> spin lock (while loof돌리기)을 주로 사용

 

<buffer에서의 동작>

- in : 비어 있는 buffer를 가리킴

- out : 차있는 buffer의 처음을 가리킴

- producer가 데이터를 생성하면 -> in은 다음을 가리킨다.

- consumer가 데이터를 소비하면 -> out도 다음을 가리킨다.

- in=out 이면 소비할 데이터가 없다는 뜻

- consumer : spin lock이 in과 out이 같을 동안 계속된다.

- producer : spin lock이 buffer가 가득 찼을 때 실행된다.

 

IPC의 방법 2가지

1. message passing : kernel에 mail box생성하고 mail box를 통해 communication한다.

2. shared memory : 특정 프로세스의 특정 영역을 공유 영역으로 설정하여 다른 프로세스가 쓸 수 있도록 한다..

 

- shared memory

process가 shared 영역에 접근할 수 있어야 함

1. process B가 shared 영역을 생성 -> shmget 함수 (system call)

2. process A가 shared 영역에 attach -> shmat 함수 (system call)

3. 이제부터 system call 없이 B에서 쓰면 A에서 읽기 가능

 

- message passing

매번 접근할 때마다 system call(send, receive) 필요

1. communication link (mail box)를 먼저 설정해 주어야 함

2. send와 receive를 통해 communication한다.

• link에 2개 이상의 process가 연결될 수 있다.
• process쌍에 여러 개의 link가 연결될 수 있다.

<communication 종류>

1. Direct communication

- send(P, message)와 receive(Q, message)를 통해 P에서 Q로 직접 message를 전송한다. (send와 receive는 OS마다 달라질 수 있음)

- send(P, message) : P로 message를 보내라

- receive(Q, message) : Q로부터 message를 받아라

- 이때 누가 전송하며 누가 받을 것인지를 hard coding 해야 한다. -> 이 이유 때문에 잘 안 씀

- 한 쌍에 하나의 link만 허용한다.

- ex) pipe기법

 

2. Indirect communication

- 보편적으로 쓰인다.

- mail box를 먼저 설정해야 한다.

- sender는 mail box로 전달하면 mail box에서 receiver에게 보내준다.

- send(A, message) : A mail box에 message를 보내라

- receive(A, message) : A mail box로부터 message를 받아라

- mail box를 통해 여러 process들이 communication 가능하다.

- 한 쌍에 여러 개의 link 허용한다.

- link 공유 측면에서 direct communication에 비해 다양한 옵션이 있다.

- <mailbox 공유의 이슈>

=>p1, p2, p3가 mail box A를 공유할 때, p1에서 보내면 p2만 받을까, p3만 받을까, 둘 다 받을까 (하나의 link에 여러 개의 process를 연결시킬 수 있기 때문에 일어나는 이슈)

           -> 1. 하나의 link는 최대 두개의 process만 연결할 수 있게 한다

           -> 2. broadcasting: 모두에게 전송해라

           -> 3. 특정 시간에 하나의 process만이 receive를 호출할 수 있도록 해라

           -> 4. sending process가 receiver를 고를 수 있게 해라

           4가지 방법 중 어떤 것을 선택할지는 응용프로그래머가 결정한다.

- mailbox synchronization

    1. blocking (synchronous)

• blocking send : send를 한 후 message가 mailbox나 receiver로부터 받아질 때 까지 waiting state
• blocking receive : mailbox에 message가 없을 때, message가 올 때까지 waiting

어떤 옵션을 선택할 지는 응용프로그래머가 결정

    2. non-blocking (asynchronous) :

• nonblocking send : send 한 후 그냥 다음 일 바로 수행
• nonblocking receive : mailbox에 message가 없어도 다음 일 수행

 

cf) message queue의 size

1. zero capacity – message를 전송할 수 없음 -> 무슨 의미가 있을까? send함수가 호출되었는지는 구분할 수 있다.

2. bounded capacity – message의 buffer size에 제한이 있다.

3. unbounded capacity – message의 buffer size에 제한이 없다.

          

message passing vs shared memory

message passing은 system call(send, receive)를 계속 호출해야 하지만 shared memory는 처음 shared공간을 설정한 이후에는 system call을 사용하지 않아도 되므로 속도가 더 빠르다.

하지만 synchronization (spin lock) 때문에 프로그래밍은 더 어렵다는 단점이 있다.