Chapter3



Chapter Objectives

● Identify the separate components of a process and illustrate how they are represented and scheduled in an operating system.

● Describe how processes are created and terminated in an operating system, including developing programs using the appropriate system calls that perform these operations..

● Describe and contrast interprocess communication using shared memory and message passing.

● Design programs that use pipes and POSIX shared memory to perform interprocess communication.

● Describe client-server communication using sockets and remote procedure calls.

● Design kernel modules that interact with the Linux operating system.





3.1 Process Concept

OS는 다양한 프로그램을 실행한다. 초기 컴퓨터는 job을 실행하는 batch system이었고, 사용자 프로그램을 실행하는 time shared system이 등장했다. 단일 사용자 시스템에서 사용자는 여러개의 프로그램을 동시에 실행할 수 있다. 컴퓨터가 동시에 하나의 프로그램만 실행할 수 있더라도, OS는 내부 프로그래밍 활동을 지원해야 한다(메모리 관리 등). 여러 관점에서 이러한 활동들은 비슷하고, 우리는 이 모두를 process(이 책에서, job과 같은 의미)라고 부른다.

3.1.1 The Process

process의 현재 활동의 상태는 program counter의 값과 processor의 register의 내용으로써 나타난다. process의 memory layout은 다음과 같은 여러개의 부분으로 나타난다.

● text section : 실행가능한 코드

● data section : 전역변수(global variables)

● heap section : 프로그램이 실행되는 동안 동적으로 할당되는 메모리

● stack section : 함수를 호출했을 때, 임시 저장공간(function parameter, return 주소, 지역변수)





3.1.2 Process State

프로세스가 실행됨에 따라, 상태가 달라진다.

● new : 더블클릭을 통해 프로세스를 만듦.

● running : 프로세스의 text section에 있는 것이 CPU에 들어가면서 실행.

● waiting : 프로세스가 이벤트가 일어나기를 기다린다.

● ready : 프로세스가 프로세서에 할당되기를 기다린다.

● terminated : 프로세스가 종료됨.

3.1.3 Process Control Block

각 프로세스는 OS에서 process control block(PCB, 램에 저장)에 의해 나타나진다.

● Process State : new, ready, running, waiting, halted

● Program Counter : 다음에 실행할 명령의 위치 가리킨다.

● CPU registers : 레지스터는 가지수와 종류가 다르고, 컴퓨터구조에 따라 다르다. 이들은 accumulators, index registers, stack pointers, general purpose registers, condition code information을 포함한다.

● CPU scheduling information : 이 정보는 프로세스 우선순위를 포함하고, scheduling queues의 포인터, 다른 scheduling parameter를 포함한다.

● Memory management information : 이 정보는 base의 값, limit registers, page tables, segment tables를 포함한다.

● Accounting information : 이 정보는 CPU의 양과 실시간 사용, 시간 제한, 계정 개수, job, process 개수 등을 포함한다.

● I/O status information : 이 정보는 프로세스에 할당된 I/O 장치의 목록, open file의 목록 등을 포함한다.

3.1.4 Threads

프로세스는 하나의 thread의 실행을 수행하는 프로그램이다. 예를 들면, 프로세스가 워드 프로세서 프로그램을 실행할 때, 하나의 명령의 thread가 실행된다. 하나의 thread는 프로세스가 동시에 하나의 작업을 수행할 수 있게 한다. 그러므로 사용자는 문자 입력과 spell checker를 동시에 실행할 수 없다. 대부분 현대 OS는 프로세스 개념을 확장해서 프로세스가 여러개의 thread의 실행을 할 수 있고 따라서 동시에 한가지 이상의 작업을 수행할 수 있게 한다.

3.2 Process Scheduling

multiprogramming의 목적은 항상 프로세스를 실행해서 CPU 이용을 극대화하는 것이다. time sharing의 목적은 프로세스들 사이에서 CPU코어의 전환을 자주 해서 사용자가 프로그램이 실행되는 동안 상호작용할 수 있게 하는 것이다. 이러한 목적을 만족하기 위해 process scheduler가 프로그램의 코어에서의 실행을 위해 이용가능한 프로세스를 선택한다.

3.2.1 Scheduling Queues

프로세스가 시스템에 들어가면, ready queue(linked list로 저장)에 들어가서 CPU 코어에서 실행되기를 기다린다. job queue는 시스템에 잇는 모든 프로세스들이고 ready queue는 메인 메모리에 있는 모든 프로세스들이고 실행하기위해 준비하고 기다린다. device queues는 I/O 장치들을 기다리는 프로세스들이다.

3.2.2 CPU Scheduling

● Short term scheduler(CPU scheduler) : 어떤 프로세스가 실행될지 선택하고, CPU를 할당한다.

시스템에서 가끔 유일한 scheduler이고 자주 호출된다(밀리초 단위 -> 빠르다)

● Long term scheduler(job scheduler) : 어떤 프로세스를 ready queue에 넣을지 선택한다.

자주 호출되지 않는다(초, 분단위 -> 느리다)

● I/O bound process : I/O작업을 더 많이 하는 프로세스

● CPU bound process : 계산작업을 더 많이 하는 프로세스

3.2.3 Context Switch

CPU가 다른 프로세스로 전환할 때, 시스템은 이전 프로세스의 상태를 저장해야 하고, 새로운 프로세스를 위해 저장된 상태를 context switch를 통해 적재해야 한다. Context는 PCB에 있는 프로세스이다. 프로세스는 여러개지만 CPU는 한정돼 있으므로 하나의 프로세스만을 실행할 수는 없다. 따라서 다른 프로세스로의 전환이 필요한데, 이를 Context Switch라고 한다. Context Switch time은 overhead이다. OS나 PCB가 복잡할수록 context switch가 길어진다.

3.3 Operations on Processes

대부분의 시스템에서 프로세스들은 동시에 실행되고, 생성과 삭제가 동적으로 이루어진다. 따라서 이러한 시스템들은 프로세스 생성과 삭제에 대한 메커니즘을 제공한다. 프로세스 생성에 대한 메커니즘을 알아보고, 윈도우, 리눅스에서의 프로세스 생성을 알아보자.

3.3.1 Process Creation

부모 프로세스는 자식프로세스를 만들어내고, 자식 프로세스는 또 다른 프로세스를 만들어내서, 트리 프로세스를 이룬다. 대부분의 OS에서 프로세스를 process identifier(pid)를 통해 식별하고 관리한다.

자원 공유 옵션

● 부모와 자식은 모든 자원을 공유한다.

● 자식은 부모의 자원의 일부를 공유한다.

● 부모와 자식은 자원을 공유하지 않는다.

실행 옵션

● 부모와 자식은 실행을 동시에 한다.

● 부모는 자식이 종료될 때까지 기다린다.

3.3.2 Process Termination

프로세스가 마지막 statement를 실행하고나서 OS에 exit() 시스템 콜을 사용해 프로세스를 삭제할 것을 요청한다.이 때 프로세스는 상태값을 wait() 시스템 콜을 통해 기다리고 있는 부모 프로세스에 반환한다. 그리고 프로세스의 모든 자원들은 OS에 의해 할당해제된다.

부모프로세스는 자식 프로세스의 실행을 abort() 시스템 콜을 통해 종료할 수 있다. 그 이유는 자식 프로세스가 할당된 자원의 사용량을 초과했을 때, 자식 프로세스에 할당된 작업이 더이상 필요하지 않을 때, 부모 프로세스가 종료되고, OS가 부모프로세스가 종료됐을 때, 자식프로세스가 계속되는것을 허용하지 않을 때이다.

어떤 OS는 부모프로세스가 종료됐을 때, 자식 프로세스가 존재하는 것을 허용하지 않는다. 프로세스가 종료되면, 그의 모든 자식프로세스(자식프로세스의 자식프로세스…)가 종료된다. 이를 cascading termination이라고 한다.

부모 프로세스가 자식 프로세스가 종료되는 것을 wait() 시스템 콜을 이용해 기다린다. 호출은 상태정보와 종료된 프로세스의 pid를 반환한다.

pid = wait(&status);

만약 자식 프로세스가 먼저 종료하고, 부모 프로세스의 wait()가 호출되지 않았을 때, zombie process라고 한다. 그리고 부모 프로세스가 종료되었지만, 자식 프로세스가 실행중인 상태를 orphan process라고 한다.

3.4 Interprocess Communication

프로세스가 시스템에서 실행중인 다른 프로세스와 데이터를 공유하지 않는다면 프로세스는 independent이고, 프로세스가 시스템에서 실행중인 다른 프로세스에 영향을 받거나 주면 프로세스는 cooperating이다. 프로세스 cooperating하는 이유는 정보 공유(몇몇 app이 같은 정보에 관심 있을 때 그 정보에 동시에 접근할 수 있는 환경을 제공해야 한다), 계산 속도 증가(특정 작업이 빠르게 수행되기 원한다면, 작은 단위로 나눠서 다른 프로세스와 병렬로 작업을 수행해야 한다), modularity(분리된 프로세스나 쓰레드로 시스템 기능을 나누는 모듈로 방식으로 시스템을 구축할 수 있다.)가 있다.

cooperating 프로세스는 Interprocess communication(IPC)가 필요하다. IPC에는 공유 메모리, 메시지 패싱 두가지 방식이 있다.

3.5 IPC in Shared Momory Systems

3.5.1 Shared Memory

서로 소통하고싶은 프로세스간에 공유하는 메모리 공간을 shared memory라고 하며, 소통은 OS가 아닌 사용자 프로세스의 통제하에 있다. 중요한 문제는 사용자 프로세스가 그들이 공유메모리에 접근할 때 그들의 동작을 synchronize하게 하는 메카니즘을 제공하는 것이다.

3.5.2 Producer-Consumer Problem

프로세스 협력을 위한 패러다임으로, producer은 consumer 프로세스에 의해 소비되는 정보를 생산하는 프로세스이다. 예를들어, 컴파일러는 어셈블러에 의해 소비되는 어셈블리어 코드를 만들어낸다. Producer-Consumer problem의 한가지 해결책은 공유 메모리를 사용하는 것이다. producer과 consumer 프로세스가 동시에 실행되려면, producer에 의해 채워지고 consumer에 의해 비워지는 item의 버퍼가 있어야 한다. 이 버퍼는 메모리 일부에 존재하고 producer, consumer 프로세스에 의해 공유된다. producer과 consumer은 동기화돼야 하고, consumer은 생산되지 않은 item을 소비하려 하면 안된다.

두가지의 버퍼가 사용될 수 있다. unbounded buffer은 buffer의 크기에 실질적인 제한이 없다. consumer은 새로운 item을 위해 기다릴 수 있지만, producer은 항상 새로운 item을 만들어 낼 수 있다. bounded buffer은 고정된 버퍼의 크기가 존재한다. 이러한 경우는 buffer가 비어있으면(OS가 producer에 notify to wake up) consumer은 기다려야 하고, producer은 buffer가 가득 찼을때(OS가 consumer에 notify) 기다려야 한다.

3.6 IPC in Message-Passing systems

프로세스가 소통하고 그들의 동작을 동기화하기 위한 메커니즘으로, message system은 프로세스가 공유메모리에 의지하지 않고 서로 소통하는 방식이다. IPC facility는 send(message), receive(message) 두가지 동작을 제공한다. 메시지의 크기는 고정돼있거나 가변적이다.

만약 프로세스 P와 Q가 소통하고 싶다면 둘 사이에 communication link 를 만들어야 하고, send/receive를 통해 메시지를 교환해야 한다. 하지만 이때 생각해야 할 점이 어떻게 링크를 만들것인가, 두개 이상의 프로세스에 링크를 연계할 수 있는가, 한쌍의 소통하는 프로세스간에 몇개의 링크까지 있을 수 있는가, 링크의 용량은 얼마나 되는가,링크가 받아들일 수 있는 메시지의 크기가 고정인가 가변인가, 링크가 일방향인가 양방향인가 등이 있다.

3.6.1 Naming

프로세스는 명시적으로 명명해야 한다.

send(P, message) : 프로세스 P에게 메시지를 보낸다.

receive(Q, message) : 프로세스 Q로부터 메시지를 받는다.

3.7 Examples of IPC Systems

3.7.1 POSIX Shared Memory

POSIX shared memory는 memory mapped file들을 이용해 구성된다. 프로세스는 shm_open() system call로 shared momory 객체를 생성한다.

fd = shm_open(name, O_CREAT

O_RDWR, 0666);

name : shared memory 이름 (중복된 이름이 존재하지 않아야 create)

O_RDWR : 읽기, 쓰기 가능하게 create

0666 : 파일 접근 허가

객체가 생성되고 나면, ftruncate() 함수가 객체의 크기를 바이트로 구성한다.

ftruncate(fd, 4096);

3.7.2 Mach Message Passing

Mach communication은 메시지 기반이며 시스템콜도 메시지로 주고받는다. 각 작업은 생성시 두개의 메일박스를 받는다(Kernel, Notify). msg_send(), msg_receive(), msg_rpc() 이 세개의 시스템콜만이 메시지 전송할때 필요하다. 송, 수신은 flexible하며 메일박스가 가득찼을 때 4가지 옵션이 있다. 무기한 대기, n밀리초 대기, 즉시 리턴, 일시적으로 메시지 캐시

3.7.3 Windows

윈도우의 message passing facility는 advanced local procedure call(ALPC)라고 불린다. 같은 시스템의 프로세스간에 작업할 수 있다. 소통 채널을 만들고 유지하기 위해 포트(메일박스)를 쓴다.

3.8 Communication in Client-Server Systems

네트워크부분 생략…

3.8.2 Remote Procedure Calls

Remote procedure call은 네트워크 시스템의 프로세스들간에 procedure call을 추상화한다. 함수의 파라미터값을 네트워크를 통해 전달하고 리턴값을 받아온다.