728x90
반응형

#프로세스 개념

운영체제 다양한 프로그램 실행

ㄴ시분할 시스템_사용자 프로그램(user programs) OR 태스크(tasks)

*프로세스(Process)

-실행 중인 프로그램

: 프로그램 카운터와 프로세스 레지스터를 포함한 현재 진행 중인 활동

 

-프로세스의 실행; 순차적 형태 진행

 

-다양한 부분

텍스트 섹션(text section): 프로그램 코드

스택(stack): 임시 데이터 저장(e.g. 함수 매개변수, 복귀 주소, 지역 변수)

데이터 섹션(data section): 전역 변수

(heap): 실행 중 동적으로 할당되는 메모리 영역

 

프로그램; 디스크에 저장된(실행 파일) 수동적(passive) 개체

프로세스; 능동적 개체_실행 파일이 적재될 때 프로그램은 프로세스가 됨

프로그램 실행 방법

: 아이콘을 마우스로 더블 클릭/ 명령어 라인에 실행 파일 이름 입력

하나의 프로그램에서 여러 개의 프로세스 생성 가능O (e.g. 웹 브라우저 탭)

*프로세스 상태

-new: 프로세스가 생성되는 중인 상태

-running: 명령어가 실행 중인 상태

-waiting :프로세스가 어떤 사건이 일어나기를 기다리고 있는 상태

-ready: 프로세스가 처리기가 할당되기를 기다리고 있는 상태

-terminated: 프로세스가 실행을 완료한 상태

=> 프로세스 실행되면서 상태가 계속 변함 + 상태 중 하나를 가짐

 

#프로세스 제어 블록(Process Control Block(PCB))

: 각 프로세스와 관련된 정보

프로세스 상태

프로그램 카운터: 다음에 실행할 명령어의 주소

CPU 레지스터: CPU 내 레지스터 내용

CPU 스케줄링 정보: 우선순위, 스케줄링 큐 포인터

메모리 관리 정보: 프로세스에게 할당된 메모리

회계 정보: 사용된 CPU , 실행이 시작된 이후 경과된 클럭 타임, 시간 제한

I/O 상태 정보: 프로세스에게 할당된 I/O 장치, 열린 파일 목록

 

#스레드

지금까지 프로세스는 하나의 실행 흐름

-> 한 프로세스가 여러 개의 스레드 가지도록 허용

프로세스가 한 번에 하나 이상의 일 수행

e.g. 문서편집프로그램; 문자 입력 + 철자 검사

ㄴ여러 제어 흐름 -> 스레드(threads)

스레드 지원 시스템: PCB가 각 스레드 관련 정보 저장하도록 확장

 

#Linux의 프로세스 표현

PCB: C structure task_struct로 표현

<linux/sched.h> 헤더파일에 존재

 

#프로세스 스케줄링

목표: CPU 이용의 극대화/ 프로세스_다양한 큐 사이 이주

*준비 완료 큐(ready queue)

: 준비 완료 상태에서 실행을 기다리는 프로세스들의 집합

메인 메모리에 존재/ 연결 리스트로 구현

헤더: 리스트의 첫 번째와 마지막 PCB를 가리키는 포인터

PCB는 다음 프로세스 가리키는 포인터 필드 가짐

*장치 큐(device queues)

: I/O 장치를 기다리고 있는 프로세스의 집합

 

#큐잉 다이어그램(Queueing diagram)

: , 자원, 프로세스의 이동 흐름을 나타냄

 

#스케줄러

*프로세스 타입

-입출력 집중(I/O-bound) 프로세스

: 계산 < 입출력 시간

CPU 활동시간

 

-CPU 집중(CPU-bound) 프로세스

: 계산 > 입출력 시간

CPU 활동시간

*단기 스케줄러(short-term scheduler)

: CPU 스케줄러

다음 실행된 프로세스 선택

millisecond 간격으로 자주 호출 -> 빨라야 함

때때로 시스템의 유일한 스케줄러(UNIX, Window 같은 사분할 시스템)

 

#중기 스케줄링

목적: 다중프로그래밍 정도를 낮출 필요가 있을 때

*스와핑(swapping)

-swap out: 메모리에서 프로세스 제거 -> 디스크 저장

-swap in: 실행 계속하기 위해 디스크 -> 메모리 다시 적재

 

#문맥 교환

CPU가 다른프로세스 전환 시 시스템 문맥교환

~> 예전 프로세스 상태 저장/ 새 프로세스의 저장된 문맥 적재

/ 중단된 프로세스 다시 시작하기 위한 작업

프로세스 문맥(context)_PCB에 표현

CPU 레지스터 값, 프로세스 상태, 메모리 관리 등

문맥 교환 시간_오버헤드

CPU 문맥 교환 시간동안 쉼

/ 운영체제와 PCB 복잡 -> 문맥 교환 시간

 

#프로세스 생성

프로세스 실행동안 여러 개의 새로운 프로세스 생성 가능O

ㄴ부모(parent) 프로세스 -> 자식(children) 프로세스 생성

=> 프로세스의 트리 형성

프로세스 식별자(process identifier, pid) 가짐

: 프로세스 관리 및 접근하기 위한 식별자

*자식 프로세스 생성 시

-자원 옵션

: 운영체제에게 자원 요청

/ 부모가 가진 자원 사용: all 공유 OR 부분집합 OR no 공유

 

-실행 옵션

: 부모와 자식 병행하게 실행/ 부모 자식이 종료될 때까지 기다림

 

-주소 공간

: 자식은 프로세스 주소 공간 복제/ 그 공간에 새로운 프로그램 적재

*UNIX 사례

-fork() 시스템 콜: 새로운 프로세스 생성

-exec() 시스템 콜: 프로세스의 메모리 공간을 새로운 프로그램으로 대체

*Windows 사례

-Windows API 이용

-CreateProcess() vs fork()

: 새로운 주소공간 할당/ 다수의 매개변수

 

#프로세스 종료

*exit() 시스템 콜 사용

: 운영체제에 삭제 요청

종료 시점에서 자식 프로세스 -> 부모 프로세스 상태 값 반환 가능O

wait() 시스템 콜 사용

프로세스의 자원이 운영체제에 반환

*abort() 시스템 콜 사용

: 부모 프로세스에 의한 강제 종료 시 사용

-자식이 자신에게 할당된 자원을 초과 사용 시

-자식에게 배정된 태스크가 더 이상 필요X

-운영체제가 부모 종료 시, 자식의 프로세스 실행 허용X

ㄴ연쇄식 종료(cascading termination)

*wait() 시스템 콜

: 부모 프로세스가 자식 프로세스의 종료 기다릴 때

자식의 상태 정보와 종료된 프로세스의 pid 반환

pid = wait(&status)

*좀비(zombie) 프로세스

: 자신(자식)은 종료 but 부모가 아직 wait() 호출X 프로세스

*고아(orphan) 프로세스

: 부모가 wait() 호출X 종료된 프로세스

Linux, Unix

init 프로세스가 주기적으로 wait() 호출 -> 고아 프로세스 수집

 

#다중프로세스 아키텍처 – Chrome 브라우저

많은 웹 브라우저는 하나의 프로세스로 실행

=> 한 웹사이트 문제 -> 전체 브라우저 영향

*Google Chrome 브라우저

: 다중 프로세스 설계

 

-Brower 프로세스

: 사용자 인터페이스, 디스크와 네트워크 I/O 관리

 

-Renderer 프로세스

: 웹 페이지 화면에 나타내고 HTMLJavascript 처리

/ 웹 사이트 열릴 때마다 새로운 renderer 생성

/ 디스크와 네트워크 입출력이 제한된 sandbox에서 실행

-> 보안 악용의 효과 최소화

 

-Plug-in 프로세스

: plug-in 종류별로 생성

 

#프로세스 간 통신(inter-process communication, IPC)

협력적 프로세스는 프로세스 간 통신 필요

 

#공유 메모리 시스템

협력적 프로세스의 전형적인 예

생산자-소비자 문제

정보 생산(by 생산자) -> 정보 소비(by 소비자 프로세스)

구현방법(해결책): 공유 메모리

컴파일러(생산자) -어셈블리 코드-> 어셈블러(생산자/소비자) -목적 코드-> 로더(소비자)

프로세스 간 통신 원할 시 공유되는 메모리 영역

*공유 메모리 = 버퍼

: 공유 메모리 구현 -> 시스템 호출 이용

사용자 프로세스 통제 하 통신_공유 메모리 접근 및 조작 <- 개발자 작성

 

-무한 버퍼

생산자: 항상 새로운 항목 생산 가능

소비자: 버퍼 비었을 경우 -> 대기

 

-유한 버퍼

생산자: 버퍼 꽉 차 있을 경우 -> 대기

소비자: 버퍼 비었을 경우 -> 대기

동기화 문제

 

#메시지 전달 시스템

운연체제가 메시지 전달 설비 제공

ㄴ네트워크에 의해 통신하는 분산 환경에서 유용

IPC 기능_2가지 연산: send(message)/ receive(message)

*메세지 크기

-고정

시스템 수준 구현: 간단

프로그래밍 작업: 어려움

 

-가변

시스템 수준 구현: 복잡

프로그래밍 작업: 간단

*프로세스 P와 Q 통신 원할 경우

둘 사이 통신 연결(communication link) 설정

send()/ receive() ~> 메시지 교환

*연결 설정 구현(appendix 참고)

-직접적 OR 간접적

직접: 통신 원하는 두 프로세스의 하나의 연결

간접: 메일박스 OR 포트

 

-동기적 OR 비동기적

 

-버퍼링


Appendix

#메시지 전달 시스템

*직접 통신

-프로세스는 서로 상대방 명확하게 지명

send(P, message): 프로세스 P에게 메시지를 송신한다

receive(Q, message): 프로세스 Q로부터 메시지를 수신한다

 

-통신 연결 특성

연결 자동적 설정/ 통신 원하는 프로세스 쌍마다 하나씩 생성

/ 통신하는 프로세스 쌍에는 정확히 하나의 연결만이 존재

/ 연결 단방향도 가능O but 보통 양방향

*간접 통신

-메시지 -> 메일박스(포트) 보내짐 + 수신

각 메일박스는 고유한 id

/ 프로세스는 공유하는 메일박스가 있어야만 통신O

 

-통신 연결 특성

연결 프로세스가 메일박스를 공유할 때만 설정/ 많은 프로세스와 연관O

/ 각 프로세스 쌍은 여러 통신 연결 공유O/ 연결 단방향 OR 양방향

 

-연산

새 메일박스(포트) 생성 -> 메일박스~>메시지 송신+수신 -> 메일박스 없애기

 

-기본 루틴 정의

send(A, messgae): 메일박스 A로 메시지 보낸다

receive(A, messgae): 메일박스 A에서 메시지를 받는다

 

-메일박스 공유

P1, P2, P3가 메일박스 A 공유

P1 메시지 보냄; P2P3는 메시지 수신 => 누가 메시지 수신?

 

-해결책

연결 최대 두 프로세스 사이에만 설정되도록 함

한 번의 오직 하나의 프로세스만이 receive 연산O 허용

시스템이 임의로 수신자를 선택하도록 함 + 송신자는 누가 수신자인지 통지받음

*동기화

메시지 전달_blocking OR non-blocking 방식

-Blocking_동기적(synchronous)

Blocking send: 송신자_메시지가 수신될 때까지 실행X

Blocking receive: 수신자_수신할 메시지가 생길 때까지 실행X

-Non-blocking_비동기적(asynchronous)

Non-blocking send: 송신자_메시지를 보내고 다른 작업 계속

Non-blocking receive: 수신자_유효한 메시지 수신 OR Null 메시지 수신

다른 조합도 가능

ㄴ송신자 + 수신자 blocking 방식 작동할 때 rendezvous라고 부름

*버퍼링

: 연결에 부착된 메시지의 큐

 

-구현

Zero capacity

: 연결에서 전송되는 메시지를 큐에 저장X

/ 송신자는 수신자가 메시지를 받을 때까지 기다려야 함(rendezvous)

Bounded capacity

: n개의 메시지를 저장할 수 있는 길이의 큐

/ 송신자는 큐가 가득 찬 경우 기다려야함

Unbounded capacity

: 무한 개의 메시지를 저장할 수 있는 길이의 큐

/ 송신자는 절대 기다리지X

 

#POSIX 공유 메모리

*IPC 시스템 사례_POSIX

-POSIX 공유 메모리

프로세스는 우선 공유 메모리 세스먼트 만들기

shm_fd = shm_open(name, O CREAT | O RDWR, 0666);

이 인터페이스는 이미 존재하는 세그먼트 공유하기 위해 열 때도 사용

객체의 크기 지정

ftruncate(shm fd, 4096);

이제 프로세스는 공유 메모리에 데이터 쓰기 가능

sprintf(shared memory, “Writing to shared memory”);

*IPC 시스템 사례_Mach

Mach 통신; 메시지 기반

시스템 콜 조차도 메시지로 전달

각 태스크는 생성될 때 2개의 메일박스 만들어짐_Kernel + Notify

메시지 전송하기 위해 단지 3개의 시스템 콜 필요

msg_send()/ msg_receive()/ msg_rpc()

통신을 위한 메일박스 port_allocate() 시스템 콜로 만든다

송신과 수신은 융통성O

ex. 메일박스 가득 찼을 경우_4가지 옵션

무한정 기다리기/ 최대 n millisecond 동안 기다리기

/ 바로 리턴하기/ 임시적으로 메시지 캐싱하기

*IPC 시스템 사례_Windows

메시지 전달 핵심; advanced local procedure call(LPC) 설비

같은 시스템의 프로세스 사이에서만 작동

통신 채널 설정 + 유지 -> 포트(메일박스) 사용

 

-통신 작동

클라이언트; 서브시스템의 연결 포트(connection port) 객체에 대한 핸들 열기

클라이언트 연결 요청 보내기

서버; 두 개의 전용 통신 포트(communication ports) 생성

+ 그 중 하나에 대한 핸들을 클라이언트에게 반환

클라이언트와 서버는 상응하는 프트 핸들 사용

-> 메시지 + 콜백 보내기 OR 응답 기다리기

 
728x90
반응형

'💻 > 컴퓨터구조 | 운영체제' 카테고리의 다른 글

CH6. CPU Scheduling  (0) 2022.05.19
CH5. Process Synchronization  (0) 2022.05.19
CH4. Threads  (0) 2022.05.19
CH2. Operating System Structures  (0) 2022.05.19
CH1. Overview  (0) 2022.05.19
김앩옹