ggoggo
운영체제 : 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
'3-1 > 컴퓨터구조 및 운영체제' 카테고리의 다른 글
5.6 시스템 버스의 대역폭 (0) | 2022.06.15 |
---|---|
5.5 반도체 메모리 (0) | 2022.06.15 |
운영체제 : Ch2. Operating-System Services (0) | 2022.06.15 |
운영체제 : Ch 1.1 Operation System (0) | 2022.06.11 |
운영체제 : Ch 1.3 Storage Management (0) | 2022.06.10 |