운영체제 3장 Process Concept

3장 Process concept

시스템은 프로세스의 콜렉션으로 이루어 진다.

3.1 Process concept

3.1.1 The process

프로세스는 다음에 실행될 위치를 명시한 프로그램 카운터와 연관된 리소스의 집합을 가지는 active entity이다. 프로그램은 디스크에 저장된 파일 형태의 passive entity이다.

 

3.1.2 Process state

-New

-Running : Instruction이 실행 중인 상태-> 한 순간에 하나의 프로세스만 실행 가능하다.

-Wating : event를 기다리는 프로세스

-Ready : 프로세서 할당을 기다리는 프로세스

-Terminated : 종료

 

3.1.3 Process Control Block

각각의 프로세스는 OS에서 PCB로 표현되어짐.

-Process state

-Program counter

-CPU register

-CPU-scheduling information : 우선순위, 스케쥴링 큐 등등

-Memory-management information : base/limit register, 페이지 테이블, 세그먼트 테이블 등등

-Accounting information : 시간사용량 등등

-I/O status information : 프로세스에 할당된 I/O정보

 

3.1.4 Threads

 

 

3.2 Process scheduling

3.2.1 Scheduling Queues

-Job Queue : 프로세스 생성되면 들어감

-Ready Queue : 메인 메모리에 거주하고 실행을 위해 기다리는 프로세스들의 리스트

-Device Queue : 특별한 I/O 디바이스의 사용을 기다리는 프로세스의 리스트

 

3.2.2 Schedulers

OS는 특정한 기준에 의해 프로세스를 큐에서 꺼내와야 하는데 이 selection process는 scheduler에 의해 수행된다.

배치 시스템에서 프로세스들이 대용량 저장 디바이스에 스풀되는데 long-term scheduler는 pool에서 프로세스들을 선택하여 실행을 위해 메모리롤 올린다. short-term scheduler는 그 프로세스들중 누가 CPU를 차지할 지 결정한다. 둘의 가장 큰 차이는 속도차이.

롱텀 스케쥴러가 중요한 이유? I/O bound와 CPU bound 프로세스를 잘 배분하지 않으면 노는 곳이 생긴다. 타임 쉐어링 시스템같은 OS에서는 medium-term scheduler가 있다. 때때로 프로세스를 메모리에서 제거하여 멀티프로그래밍의 레벨을 늘린다. 이것을 swapping이라 한다.

 

3.2.3 Context Switch

커널 목적으로 인터럽트가 발생하면 시스템은 CPU에서 실행중인 프로세스의 context를 저장하여야한다. 컨텍스트는 프로세스의 PCB로 나타난다.

컨텍스트 스위치 : 실행중인 프로세스의 스테이트 저장. 실행될 프로세스 스테이트 로드

이 시간은 오버헤드이며 하드웨어에 의존한다.

 

 

3.3 Operations on Processes

3.3.1 Process Creation

프로세스는 시스템콜을 통해 생성되는데 creating process가 parent process이고, 새로운 프로세스가 children process이다.

각각의 프로세스는 integer 형태의 unique pid로 식별된다.

실행시 주소에 있어서 두 가지 옵션이 있다.

1. 부모를 복제한다.

2. 새로운 프로그램이 생긴다.

1번이 리눅스의 경우이다.

fork()시스템콜의 경우 child의 경우에는 리턴값이 0이고 parent의 경우에는 pid이다.

일반적으로 fork()를 사용하고 자식에서 exec()로 새로운 프로그램을 실행시키는 형태로 사용한다.

exec()는 binary file을 메모리에 올리고 실행을 시작한다. 부모는 wait()실행시 자식을 기다린다.

자식은 부모의 권한이나 스케쥴링 속성등을 상속받는다.

윈도우는 2번의 경우이고 CreateProcess()로 프로그램을 만들며 메모리 공간을 미리 할당하고 호출한다.

 

3.3.2 Process Termination

프로세스는 마지막 구문을 실행하였거나 exit() 시스템콜을 요청하였을때 terminate한다. child는 parent에게 status value를 리턴한다. 모든 리소스는 해제된다.

어떠한 OS에서는 부모가 죽었을 경우 자식도 같이 죽는데 그것을 cascading termination이라고 한다. 유닉스의 경우에는 부모가 먼저 죽었을 경우 자식이 init 프로세스를 새로운 부모로 가지게 한다.

 

 

3.4 Interprocess communication

프로세스가 다른 프로세스에게 영향을 받지도 주지도 않을경우 indepedent이고 그렇지 않을 경우 cooperating process이다. 다른 프로세스와 데이터를 공유하면 cooprate이다.

장점 : (1)정보공유 (2) 계산속도 증가 (3) 모듈러리티 (4) 편리함

Cooperating 프로세스는 IPC를 요구한다. 데이터를 주고받기 위해.

(1) shared memory : 빠르다. 메모리 공간 할당받으면 메모리 접근처럼 사용가능하다.

(2) message passing : 짧은 데이터에 유용-confilct를 피하기 때문에  그리고 구현하기 쉽다.

 

3.4.1 Shared-Memory Systems

공유 메모리를 사용하기 위해서는 영역을 설정해야한다.  공유메모리 영역은 공유메모리 세그먼트를 만드는 프로세스의 메모리 영역안에 있다. 접근하려는 프로세스는 그들의 메모리에 부착해야 한다. 일반적으로 OS에서 다른 프로세스의 메모리 영역에는 접근할 수 없지만 이것은 에외이다. 그러므로 운영체제는 이것에 대한 책임이 없고 프로세스들이 같은 위치에 동시 사용하지 않는 것에 대한 책임을 진다.

 

3.4.2 Message-Passing System

메시지 패싱은 그들의 데이터를 동기화 할 수 있어 특히 분산 환경에서 유용하다.(다른 컴퓨터인 경우)  메시지 패싱은 두가지의 동작을 제공한다.  send와 receive이다. 고정 사이즈이거나 변하는 사이즈이다. 고정 사이즈인 경우 프로그램이 어렵다. 변하는 사이즈의 메시지일 경우 시스템 레벨에서의 구현은 복잡하지만 프로그래밍은 쉬워진다. 메시지로 커뮤니케이션 하기 위해서는 communication link가 구성되어야 한다.

여러 가지 기준에 의해 나눌 수 있다.

 

3.4.2.1 Naming

direct commnuication에서는 각각의 프로세스는 리시버나 센더의 이름을 명시해 준다.

커뮤니케이션을 원하는 각각의 프로세스들 끼리 링크가 확립된다. 링크는 2개의 프로세스만 가능하며 각 프로세스의 쌍에는 오직 1개의 링크만 가능하다. 위와같은 것을 symmetry라 하며 이것의 변종으로 asymmetry도 있는데 여기서는 센더만 리시버의 이름을 넣어준다. 이 두개 모두의 단점은 프로세스 정의 결과(?)의 제한된 모듈러리티이다. 아이덴티파이어를 바꾸면 프로그램을 다바꿔줘야한다.

indirect communication에서는 메시지는 mailboxes 또는 ports를 통해서 주고받을수 있다. 메일박스는 추상적인 오브젝트이고 메시지가 들어가고 나갈 수 있다. 프로세스는 공유된 메일박스를 가질 때에만 대화할수 있다. 메일박스의 링크는 2개 프로세스 이상이 접근할 수 있으며 각 쌍의 프로세스에 여러개의 링크(메일박스)가 존재할 수 있다. 메일박스는 프로세스가 소유할 수도 있고 os가 소유할 수도 있다. 프로세스가 소유하면 owner가 명확하므로 누가 보내고 받는지에 대한 것이 명확하다. os가 가지면 메일박스를 만들고, 보내고 받고, 없애는 메커니즘을 제공해야 하며 메일박스를 만든 프로세스가 기본적으로 오너가 된다.

 

3.4.2.2 Synchronization

센드와 리시브는 blocking/nonblocking으로 나뉘어서 누가 보냈고 받았는지의 여부를 블락킹을 이용해서 판단할 수 있다.

 

3.4.2.3 Buffering

메시지는 큐에 저장되는데 capacity별로 세 가지로 나뉜다.

첫번째가 zero capacity이고 버퍼의 크기가 없으므로 센더는 무조건 블락킹 센드를 해야한다. 둘째는 Bounded capacity이다. 유한의 길이 n을 가진다. 어느정도까지는 기다리지 않고 전송하지만 꽉차면 블락해야 한다. 마지막으로 unbounded인데 크기 제한이 없으므로 블락 안한다.