SP - 1.3 프로세스와 프로세스 컨트롤

Process

1.1, 1.2 포스팅을 통해 우리는 프로세스의 정의를 아래와 같이 확인한 바 있다.

Process : Instance of a Running Program

Process : 프로그램이 메모리에 '명령어의 시퀀스'로 적재된 후, CPU를 동작시킬 수 있는 상태가 되었을때, 그 프로그램을 일컫는 용어

프로그램이 '(기계어) 명령의 집합'이고, 이를 컴파일, 어셈블, 링크, 로드하면 메모리에 적재된다. Program Counter가 메모리 내의 '프로그램의 Code 부분'을 가리키고, CPU는 이를 실행하게 된다.

~> 이때, 마치 여러 프로세스가 각각의 CPU를 독점하고 있는 것처럼 보이지만, 실상은 단일 CPU가 Time-Sharing을 하면서 여러 프로세스를 처리하고 있다.

~> 예를 들어, 10ms의 Time Quantam을 기준으로 Context Switch를 해가며 각 프로세스를 순차적으로 부분부분씩 처리하고, 반복한다고 했다.

이러한 프로세스는, 각 프로그램에게 다음과 같은 두 종류의 추상화를 제공한다고 했다.

Logical Control Flow with Context Switch
Private Address Space with Virtual Memory of OS
~> 이 중, Logical Control Flow에 대해 조금 더 자세히 파헤쳐보자.

Logical Control Flow

만약, 프로세스 p1과 p2가 있고, 단일 CPU가 있다고 해보자.

CPU 안에는 Register Set이 있고, 그 안에는 PC(Program Counter), IR, 범용 레지스터(ex. EAX, EBX, ..)와 같은 레지스터들이 있다.
p1이 수행되고 있다고 하면, CPU의 PC는 p1의 메모리 부분에서 code 부분의 명령을 가리키게 된다.
- 이때의 Context는 p1인 것이다.
- 그렇게 쭉 p1의 명령을 수행하다가, 일정 시간의 Time Quantam이 지나가면 비동기적인 Timer Interrupt에 걸리게 된다.
인터럽트가 걸리면, OS 커널 공간 안에 있는 Timer Interrupt Handler가 수행되어, 이 핸들러가 'Context Switch'를 수행한다.
- p1과 관련된 각 레지스터의 저장물들을 커널 내의 특정 메모리 공간(Saved Registers)에 Save한다.
이제 p2가 수행되기 시작한다. 커널 내의 p2와 관련된 저장물들이 있는 메모리 공간(Saved Registers)에서 정보들을 가져와 CPU의 Register Set에 Update한다.
- 이어서 p2의 명령을 수행하게 된다.

~> 마치 각 프로세스들이 각각 메모리와 CPU를 가진 것처럼 추상화되어 동작한다.
(Logical Control Flow + Private Address Space)

※ 메모리 : Kernel Space + User Space

User Space에는 프로그램이 적재되어 Stack-Heap-Data-Code 등의 부분이 각 프로세스마다 할당되고, Kernel Space에는 Saved Registers 부분이 있다.

Concurrent & Sequential Processes

프로세스의 코드 부분이 수행될 때, 만약 프로세스의 명령어가 100개 있다면, CPU는 단순하게 그 100개의 명령어를 순차적으로 읽으면서 수행한다. 'Physical Control Flow(Fetch->Decode->Execute->WriteBack)'를 지켜가면서 말이다.

한편, 만약 두 프로세스를 돌릴 때는 어떨까?

Concurrent Processes : 두 개의 프로세스의 시작부터 끝날때까지의 시간 간격이 겹치는 경우, 이 두 프로세스의 관계를 Concurrent Processes라고 한다.

Sequential Processes : 반대로, 두 개의 프로세스의 시작-끝 시간 간격이 서로 겹치지 않는 경우, 두 프로세스의 관계를 Sequential Processes라고 한다.

~> 즉, 두 프로세스 간의 관계를 나타내는 용어이다.

A와 B, A와 C는 시간 간격이 겹치고 있으므로 Concurrent Processes이다.
B와 C는 시간 간격이 안 겹치고 있으므로 Sequential Processes

~> Concurrent Processes의 Control Flow를 보면, 우리 눈에는 동시에 병렬적으로 각각 수행되고 있는 것처럼 보이지만, 실상은 물리적으로 Disjoint하다는 것이다.

Context Switching Overhead

Pa와 Pb가 있다. 둘 다 프로세스이고, Code+Stack의 메모리만 가진다고 해보자. Stack에는 지역변수들, Code엔 소스 코드가 들어간다. 두 프로세스는 메인 메모리 어딘가에 상주하고 있다.
이때, 메인 메모리는 User 부분과 Kernel 부분으로 나뉜다고 했다.
- Kernel 부분은 사용자 입장에서는 사실상 절대 접근할 수 없다.
- 일반적으로 메인 메모리가 4GB라 하면, 약 1GB 정도는 커널 부분으로 할당된다.
만약 이때 System Call(Interrupt or Trap), 예를 들어서 read를 했다고 해보자.
- 이 read는 OS의 read 함수를 호출한다. (Interrupt의 예시)
- 프로그램을 수행하다가, 시스템 콜을 만나면, OS 커널 공간의 read 함수 부분으로 점프를 하는 것이다.
  - 이 과정이, 마치 커널 함수가 프로세스의 하나의 영역인 것처럼 돌아가게 된다.

OS가 '메인 메모리에 상주하고 있는(Memory-Resident)' 부분을 커널(Kernel)이라 하는데, 커널 부분의 코드는 마치 기존의 프로세스의 어떤 영역처럼 돌아가게 된다.

커널 함수 부분과 프로세스 부분이 Not Separte인 것처럼 보인다는 것이다.

한편, Control Flow는 Context Switch를 통해 한 프로세스에서 다른 프로세스로 넘어간다고 했다.
예를 들어, Pa 프로세스가 실행될 때, Time Quantam이 10ms라 하면, 10ms만큼 돌았을 때, Timer Interrupt가 걸려 OS 커널 내의 함수인 Timer Interrupt Handler가 마치 Pa의 일부분인 것처럼 동작한다는 것이다.
- 이때, 핸들러가 'Next Process'를 Schedule한다.
- 이러한 핸들러가 동작하는 시간을 'Context Switch Overhead'라고 부른다.

~> 즉, Pa 프로세스가 타이머 인터럽트가 걸려 끝나고, Context Switch Overhead가 지나간 다음, Pb(Pnext) 프로세스가 수행된다는 것이다.

Process Control

이제 프로세스를 개념적인 분석을 넘어, 실제 코드 레벨에서 분석해보자.

"ls -al"

우리가 Shell에서 'ls -al'이라는 명령을 치면, files와 directories에 대한 Info가 화면에 출력된다.

이때, 'ls'는 무엇일까?
- ls는 프로그램이다. 현재 디렉토리에 있는 모든 디렉토리와 파일들을 화면에 출력하는 기능을 수행하는 프로그램이다. (Linux 기준 /bin에 들어있다.)
  - OS 안에 File System에 대한 정보들이 있고, ls 프로그램은 System Call들을 여러 번 하여 이 정보를 긁어오는 것이다.
- 이 ls 프로그램은, 우리가 쉘을 실행해놓고 '> ls'라고 타이핑을 하고 Enter를 치는 순간, 프로세스가 되는 것이다.
  - Enter를 치는 순간, ls 프로그램에 대한 정보가 'Code, Stack, Heap, Data'의 부분으로 나뉘어 메인 메모리에 적재된다.
  - CPU의 PC가 ls의 code 부분의 첫 번째 명령부터 Fetch하면서 흐른다.

Shell & fork

한편, OS에 요청하는 System Call 중에는 fork라는 System Call이 있다.

fork : 프로세스를 생성하는 System Call이다.

UNIX 계열의 OS는 모든 프로그램에 대해 fork라는 System Call을 하여 프로세스화한다.

위의 예시에서, ls 프로세스는 '>' 프로세스가 fork하여 만들어진 것이다.
- '>'는 ls의 parent process, ls는 '>'의 child process이다.
  
  '>'는 Shell이라는 프로세스이다.
  - Shell은 Command 입력을 기다리는 단순한 프로그램이다.
  - 그렇다. 사실 메인메모리에는 이미 Shell이라는 프로세스가 돌고 있던 것이다.
  - 우리가 Shell에서 ls라는 프로그램을 만드는 순간, 두 프로세스가 Concurrent Processes가 된 것이다.
그렇다면, 이 Shell 프로세스는 누가 생성한 것일까?
- UNIX 계열에는 가장 Ancestor에 해당하는 프로세스인 'Init'이라는 프로세스가 존재한다.
  - Init이 '프로세스 트리'를 형성하면서 쭉 프로세스를 만들어가게 되는 것이다.
  - 이러한 트리 구조에는, Parent-Child 관계가 형성되어 있고, 우리 컴퓨터에서 돌아가는 수많은 프로세스는 모두 이 Init이라는 하나의 조상으로부터 뻗어나온 것이다.

Fork의 이해

System Call Error Handling

일반적으로, 오류가 발생하면 Linux System에서는 함수의 반환값으로 -1을 부여하고, 전역 변수 'errno'에 에러의 원인을 명시한다.
~> 그래서, 시스템을 다루는 프로그래밍을 할 경우, 우리는 항상 에러 상황을 고려해야한다.

System-Level Function의 return값은 '에러 유무'를 알려주므로, 항상 이 반환값에 주의해야한다.

if ((pid = fork()) < 0) {			// 이 fork가 System Call이다.
	fprintf(stderr, "fork error: %s\n", strerror(errno));
	exit(0);
}

~> 위에서 언급한 fork함수를 사용하는 간단한 코드이다. fork는 System Call, 즉, System-Level Function으로, 언급한 것처럼 반환값을 체크해 에러 여부를 확인하고 있음을 주목하자.

Error-Reporting Function 스킬

시스템 콜 관련해서 에러가 날 경우, 이를 아예 명시적으로 "어떠한 에러가 났다!"를 화면에 출력하는 프로그래밍 스킬이 있다.
~> 이를 위해선, 일반적으로 아래와 같은 꼴의 'Error-Reporting Function'을 정의한다. (UNIX 계열 시스템 프로그래밍 상황이 기준이다.)

void unix_error_report(char *msg) {
	fprintf(stderr, "%s: %s\n", msg, strerror(errno));
	exit(0);
}

~> 이러한 스킬을 적용하면, 위의 예시 코드를 아래와 같이 변형할 수 있다.

if ((pid = fork()) < 0)
	unix_error_report("fork error");

~> 그리고, 이를 이용해 아래와 같이 '에러 보고 기능'을 탑재한 Fork 함수를 만들어 사용할 수 있다.

pid_t Fork(void) {
	pid_t pid;
    
	if ((pid = fork()) < 0)
		unix_error_report("Error in Fork()!");
        
	return pid;
}

여담) 이러한 코딩 스타일을 'Stevens-Style Error-Handling Wrappers'라고 한다. (랩핑을 씌워놓은거 같다고 해서 Wrapper라고 한다.)

fork System Call

int main(void) {
	pid_t pid;
	int x = 0;

	pid = Fork();
    
    /* Child Process */
	if (pid == 0) { 	
		printf("child : x=%d\n", ++x); 
		exit(0);
	}

	/* Parent Process */
	printf("parent: x=%d\n", --x); 
	exit(0);
}

(출력 예시)
parent: x=-1
child: x=1
(또는)
child: x=1
parent: x=-1

프로세스가 Code와 Stack 부분을 가진다고 해보자.
- pid와 x는 Local Variable이므로 Stack 메모리 부분으로 들어간다.
이때, CPU가 이 프로세스를 실행하는데, 'Error-Handling Wrapper' 처리가 된 Fork 프로시저를 만난다.
- Fork 내부의 실제 System Call인 fork가 수행된다. ~> System Call이므로, 커널에 있는 fork 함수 부분이 수행되는 것이다. 마치 이 프로세스의 일부분처럼(Trap)!
이때, 커널의 fork는 현재 프로세스(이를 Pa라고 부르자)와 똑같은 코드를 복사해 메인 메모리에 적재한다. Pa를 Parent, 새로 생기는 프로세스를 Child라고 한다.

fork라는 System Call은 현재 프로세스의 코드를 똑같이 복제해 메모리에 적재한다.

fork 함수는 parent에겐 0이 아닌 값을, child에겐 0을 반환한다. (구분을 위해)

이때, 두 프로세스에 대한 커널의 Saved Registers 부분에는 둘 다 PC가 논리적으로 fork 수행 직후에 위치한 명령어를 가리킨다.

즉, Pa와 Pa_child의 Context가 커널 공간에 복사되어 있는데, 둘의 PC는 모두 논리적으로 같은 위치에 있다는 것이다. 말그대로, 그냥 복사한 것이다.

잊지말자, 현재 우리가 논하는 fork의 목적은 '프로세스 생성'이다.

~> 즉, 우리는 새로운 프로그램을 로딩할 때, fork System Call의 결과로 생긴 Child Process에 원하는 프로그램을 넣는(이 과정은 다음 포스팅에서 설명) 방식으로 수행하는 것이다.

~> 이때, Parent와 Child는 Concurrent Processes가 되므로 Timer 상황에 따라서 parent부터 수행될지, child부터 수행될지 알 수 없다.
=> 그래서, 위의 출력 결과가 두 가지가 가능한 것이다.

Process Control 관련 추가 개념

※ Process ID를 얻는 함수
pid_t getpid(void) : 현재 Process의 PID 반환
pid_t getppid(void) : Parent Process의 PID 반환

프로그래머 입장에서의 Process 상태

Running : 프로세스가 실행중이거나, 또는 프로세스가 커널에 의해 스케쥴된 후, 실행되기 전에 기다리고 있는 상태 (Running & Ready)
Stopped = Blocked = Waited = Skipped : 프로세스가 수행이 잠시 Suspend되고, 아직 언제 실행될 것이라 스케쥴되지 않은 상태
- Running에 포함되는 Ready와 Stopped에 포함되는 Waited의 차이 : OS 커널에 의해 실행이 스케쥴되었는가 아닌가로 구분한다.
실행되기로 예정되었으면 Ready(Running), 아직 스케쥴되지 않았으면 Waited(Stopped)
Terminated : 프로세스가 어떠한 Signal에 의해 종료된 상태
Done : 프로세스가 수행을 마치고 (정상) 종료된 상태

프로세스 종료 - exit

프로세스가 종료되는 3가지 이유
- 디폴트 액션이 '종료(Terminate)'인 Signal을 프로세스가 Receive한 경우
- 프로세스의 main함수가 return한 경우
- exit함수를 호출한 경우
exit함수 : void exit(int status)
- 'Exit Status'와 함께 종료한다.
- 일반적인 종료의 경우 0을 반환하고, 에러 상황의 경우 0이 아닌 값을 반환하는 관습이 존재한다.
- 명시적으로 Exit Status를 특정 정수값으로 나타낼 수 있다.

exit함수의 주요 특징 : return하지 않고 그냥 종료된다. (위에서 반환이라 표현한 것은 status 인자를 변경하는 것을 의미. exit 함수 자체는 반환이 void임.

프로세스 생성 - fork

Parent Process가 fork System Call을 이용해 새로운 Child Process를 생성한다.
fork함수 : int fork(void)
- Child Process에겐 0을, Parent Process에겐 0이 아닌 값을 반환한다.
- Child Process는 Parent Process를 그대로 복사한다.
  - Identical하지만 Separate된 (가상 메모리 주소) 위치에 Child가 존재하게 된다.
  - 하지만, Child의 PID는 Parent와 다르다.

fork함수의 주요 특징 : 한 번 호출되면, 두 번의 반환을 수행한다. ★★★

Process Graph를 통한 fork Modeling

우리는 'Process Graph'를 이용하여 Concurrent Program(Processes)의 Partial Ordering을 표현할 수 있다.

그래프의 각 Vertex는 '명령의 수행'을 나타낸다.
- printf가 담긴 Vertex의 경우 Output으로 레이블화할 수 있다.
'a -> b'는 a가 b보다 먼저 수행됨을 의미한다.
그래프의 각 Edge는 현재 변수들의 값으로 레이블화할 수 있다.
그래프의 시작 Vertex는 In-Edge가 없다.

~> Process Graph를 어떻게 Topological Sorting하든, 그 결과는 Feasible한 Total Ordering이다.

~> 이때, 이 Partial Ordering은 좌에서 우로 흐르게 그리곤 한다.

Author And Source

이 문제에 관하여(SP - 1.3 프로세스와 프로세스 컨트롤), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://velog.io/@junttang/SP-1.3-프로세스와-프로세스-컨트롤

우수한 개발자 콘텐츠 발견에 전념 (Collection and Share based on the CC Protocol.)