운영체제 : Ch3. Processes

Process Concept

• 운영체제는 프로세스로 실행되는 다양한 프로그램을 싱행
• 프로세스

실행중인 프로그램.

프로세스 실행은 순차적으로 진행되어야 한다. 

단일 프로세스에서 병렬로 명령 실행하지 않음

• Multiple parts

- 텍스트 섹션이라고도 하는 프로그램 코드

- 프로그램 카운터, 프로세서 레지스터를 포함한 현재 활동

- 임시 데이터를 포함하는 스택

  => 함수 매개변수, 반환 주소, 지역 변수

- 전역변수가 들어 있는 데이터 섹션

- 런탕미 동안 동적으로 할당된 메모리를 포함하는 힙

 

• 프로그램은 디스크에 저장된 패시브 엔티티, 수동적인 독립체(파생 가능 파일)이며 프로세스가 활성 상태이다.

=> 실행 파일이 메모리에 로드되면 프로그램이 프로세스가 됨

• GUI 마우스 클릭, 이름  명령 줄 입력 등을 통해 프로그램 실행 시작
• 하나의 프로그램이 여러 프로세스가 될 수 있음

=> 동일한 프로그램을 실행하는 여러 사용자 고려

Process in Memory

- data / text : 고정

- heap : 동적

- stack : 쌓음

Memory layout of a C Program

Process State

• 프로세스가 실행됨에 따라 상태가 바뀜

- New : 프로세스를 만드는 중

- Running : 명령이 실행 중

- Waiting : 프로세스가 일부 이벤트가 발생하기를 기다리는 중

- Ready : 프로세스가 프로세서에 할당되기를 기다리는 중

- Terminated : 프로세스가 실행을 완료

Diagram of Process State

Process Control Block (PCB)

각 프로세스와 관련된 정보(task control block 이라고도 함)

• Process State - 실행 중 , 대기 중
• Program counter - 다음 실행 지침 위치
• CPU register - 모든 프로세스 중심 레지스터의 내용

* register : CPU 내에서 자료를 보관하는 아주 빠른 기억장소. 현재 프로세서는 메인 메모리에ㅓㅅ 레지스터로 데이터를 옯겨와 데이터를 처리한 후 그 내용을 다시 레지스터에서 메인 메모리로 저장하는 방식 사용

• CPU scheduling information - 우선 순위, 스케줄링 대기열 포인터
• Memory 관리 정보 - 프로세스에 할당된 메모리
• Accounting infomation(계정정보) - CPU 사용, 시작 후 경과된 클럭 시간, 시간 제한
• I/O status informaiton - 프로세스에 할당된 I/O장치, 열린 파일 목록

Threads

• 지금까지 프로세스는 단일 스레드의 실행
• 프로세스 당 프로그램 카운터가 여러개 있는 것 고려!

=> 한 번에 여러 위치를 실행할 수 있음

     => 다중  thread 조절 -> threads

• 그러면 PCB(Process Control Block)에 여러 프로그램 카운터, 스레드 세부 정보를 저장할 수 있는 저장소가 있어야 한다.

Process Representation in Linux

Process Scheduling

• Process Scheduler는 CPU 코어에 대한 다음 실행에 사용할 수 있는 프로세스 중 하나를 선택
• 목표 = CPU 사용 극대화, CPU 코어로 신속하게 프로세스 전환
• 프로세스의 스케줄링 대기열 유지

- Ready queue : 주 메모리에 상주하며 실행 준비가 되어 있고 대기 중인 모든 프로세스의 집합

- Wait queues : 이벤트 대기 중인 프로세스 집합(ex.. I/O)

- 프로세스가 다양한 대기열로 이주

Ready and Wait Queues

Representation of Process Scheduling

CPU Switch from Process to Process

Context Switch

• CPU가 다른 프로세스로 전환되면 시스템은 이전 프로세스의 상태를 저장하고 context  switch를 통해 새 프로세스에 대해 저장된 상태를 로드해야 한다.
• PCB에 표시되는 프로세스의 컨텍스트
• Context-swith time 은 단순한 overhead이며, 전환 중에는 시스템이 유용하게 작동하지 않는다

- OS와 PCB가 복잡할수록 Context-switch가 길어진다.

• 하드웨어 지원에 따른 시간

- 일부 하드웨어는 CPU 당 여러 레지스터 세트를 제공 -> 여러  context를 한번에 로드

Process Creation

• 상위 프로세스는 하위 프로세스를 생성하고, 하위 프로세스는 다른 프로세스를 생성하여 프로세스 트리를 형성
• 일반적으로 Process Identifier(pid)를 통해 process 파악 및 관리
• 리소스 공유 옵션

- parent and children은 모든 리소스 공유

- children은 parent 소스의 subset 공유

- parent와 child는 리소스 공유x

 

• 실행 옵션

- parent 및 children 동시 실행

- 부모가 하위 항목이 종료될 때까지 기다림

 

• 주소 공간 옵션

- 하위 항목이 상위 항목의 중복 항목

- child는 새 프로그램을 로드

 

• Unix의 예

- fork() 시스템 호출은 새로운 프로세스를 만든다.

- exec() 시스템 호출은 프로세스의 메모리 공간을 새 프로그램으로 대체하기 위해 fork()뒤에 사용

- 부모 프로세스는 wait()을 호출해 자식 프로세스가 종료될 때까지 기다림

C Program Forking Separate Process

Creating a Separate Process via Windows API

Process Termination

• Process는 마지막 문을 실행한 후 exit() 시스템 호출을 사용하여 OS에 삭제를 요청

=> 대기 중인 부모에게 상태 데이터를 반환 (wait()을 통해)

=> 프로세스의 리소스가 운영 체제에 의해 할당 취소됨

• 부모는 abort() 시스템 호출을 사용하여 자식 프로세스의 실행을 종료할 수 있다.

아래의 이유 때문에

- 하위 항목이 할당된 리소스를 초과

- 하위 항목에 할당된 작업이 더이상 필요하지 않음

- 상위 항목이 종료되고 있으며 상위 항목이 종료된 경우 운영 체제에서 하위 항목이 계속하도록 허락x

• 일부 운영체제에는 상위 항목이 종료된 경우 하위 항목이 존재할 수 없다. 프로세스가 종료되면 모드 ㄴ하위 프로세스도 종료해야 한다.

- cascading 종료(계단식) 모든 자녀, 손자, 손녀 종료

- OS에 의해 종료됨

• 상위 프로세스는 wait() 시스템 호출을 사용하여 하위 프로세스의 종료를 기다릴 수 있다. 호출은 상태 정보와 종료된 프로세스의 pid = wait(&state)를 반환
• 프로세스가 종료되었지만 부모가 아직 wait을 호출하지 않으면 프로세스는 zombie
• parent가 wait()을 호출하지 않고 종료된 경우 프로세스는 orphan

Multiprocess Archtecture -Chrome Browser

• 많은 웹브라우저가 단일 프로세스로 실행되었음.(IE는 여전히)

=> 한 웹 사이트에서 문제가 발생하면 전체 브라우저가 중단되거나 중단될 수 있다.!

• Google Chrome Browser는 세 가지 유형의 프로세스를 갖툰 다중 프로세스

1) Browser 프로세스에서 사용자 인터페이스, 디스크 및 네트워크 I/O관리

2) Rederer 프로세스는 웹 페이지를 렌더링하고 HTML, Javascript를 처리.

   각 웹사이트에 대해 생성된 새 rederer는

     => Sandbox에서 실행되어 디스크 및 네트워크 I/O를 제한하고 보안 공격 효과를 최소화 "보안"

3) Plug-in 프로세스는 각 플러그인 유형에 관한 것

Interprocess Communication

• 시스템 내 프로세스는 독립적이거나 협력적일 수 있다.
• 협력 프로세스는 데이터 공유 등 다른 프로세스에 영향을 미치거나 영향을 받을 수 있다!
• 협력 프로세스 이유 :

- 정보 공유

- 계산 속도 향상

- 모듈성

- 편리성

• 협력 프로세스는 Interprocess communicaton(IPC) 필요

=> 2가지 모델 

(1) 공유 메모리

(2) 메시지 전달

Producer - Consumer Problem

• 협력 프로세스 패러다임 :

producer 프로세스는 consumer 프로세스에 의해 소비되는 정보를 생산

• 두 가지 변형 :

(1) unbounded-buffer : 무한 확장 기능은 버퍼 크기에 실질적인 제한을 두지 않는다.

   - producer는 기다리지 않는다.

   - 소비할 버퍼가 없는 경우 consumer가 대기

(2) bounded-buffer : bounded-interval은 고정된 버퍼 크기가 있다고 가정

   - 모든 버퍼가 꽉 찬 경우 생산자가 기다려야 함

   - 소비할 버퍼가 없는 경우 소비자가 대기

IPC - Shared Memory

• 통신을 원하는 프로세스 간에 공유되는 메모리 영역
• 통신은 운영체제가 아닌 사용자 프로세스에 의해 통제됨
• 주요 문제는 사용자 프로세스가 공유 메모리에 액세스할 때 작업을 동기화할 수 있는 메커니즘을 제공하는 것

Bounded-Buffer - Shared-Memory Solution

공유된 메모리

 => Producer

 =>Consumer

Direct Communication

• 프로세스는 서로 명시적으로 이름을 지정해야 함

- send (P, message) - 프로세스 P로 메시지 보내기

- receive (Q, message) - 프로세스 Q로부터 메시지 받기

• 통신 링크의 특성

- 링크는 자동으로 설정

- 링크는 정확히 한 쌍의 통신 프로세스와 연결됨

- 각 쌍 사이에는 정확히 하나의 링크가 존재

- 링크는 단방향일 수 있지만 일반적으로 양방향

Indirect Communication

• 메시지는 우편함(== port)에서 전달 및 수신

- 각 mailbox는 고유 ID 가진다

- 프로세스가 mailbox를 공유하는 경우에만 통신할 수 있다

• 통신 링크의 특성

- 프로세스가 공통 편지함을 공유하는 경우에만 링크가 설정됨

- 링크는 많은 프로세스와 연관될 수 있음

- 각 프로세스 쌍은 여러 통신 링크를 공유할 수 있다

- 링크는 단방향 또는 양방향

• operation(동작)

- 새 mailbox(=port)만들기

- mailbox를 통해 메시지 보내기 및 받기

- mailbox 삭제

• 초기 요소

- send(A, message) - mailbox A로 메시지 보내기

- receive(A, message) - mailbox A에서 메시지 받기

• mailbox 공유

- p1,p2,p3가 mailbox A 공유

- p1 sends; p2,p3 receive => 누가 받아???

 

=> 해결책

- 링크를 최대 두개의 프로세스와 연결하도록 허용

- 한 번에 하나의 흐로세스만 수신작업 실행 허용

- 시스템이 수신기를 임의로 선택한 후 보낸 사람은 수신자가 누구였는지 알림.

Syncronization

메시지 전달은 blocking 또는 non-blocking 일 수 있다.

• Blocking은 동기식으로 간주

- Blocking send - 메시지를 수신할 떄까지 발신인이 차단됨

- Blocking receive - 메시지를 사용할 수 있을 때까지 수신기가 차단됨

• Non-blocking은 비동기식으로 간주

- Non-blocking send - 발신인이 메시지를 발송하고 계속함

- Non-blocking receive - 수신기는 다음을 수신

  => 유요한 메시지거나 NULL 메시지거나

• 다른 조합 가능

송신과 수신이 모두 차단되는 경우 Randezvous