프로세스 -> 컴퓨터에서 실행되는 프로그램
스레드 -> 프로세스 내 작업의 흐름
1. 프로세스와 컴파일 과정
프로세스 -> 프로그램으로부터 인스턴스화(실행되는 것과 같은 의미)
프로그램 -> 컴파일러 - 기계어로 번역 되는 것
전처리
- 소스 코드의 주석 제거 및 헤더 파일을 병합
컴파일러
- 어셈블리어로 바꿔주는 것
어셈블러
- 어셈블리어는 object 코드로 변환되는 것
링커
- 다른 파일들과 목적코드를 병합 후, 실행 파일 만듬 .java같은 것
(a) 정적 라이브러리
- 프로그램 빌드할 때 라이브러리가 제공하는 모든 코드를 실행 파일에 넣는 것
- 외부 의존도 낮음 + 효율성 떨어짐(코드 중복 O)
(b) 동적 라이브러리
- 필요한 코드만 넣는 것
- 외부 의존도 높아짐 + 효율성 높음(코드 중복 X)
2. 프로세스의 상태
생성 상태
- create -> 프로세스가 생성된 상태 + PCB 할당
(a) fork()
- 부모 프로세스의 주소 공간을 복사(비동기 작업은 상속 X) -> 새로운 자식 프로세스 생성
(b) exec()
- 그냥 새롭게 프로세스를 생성하는 것
대기 상태
- ready
- 메모리 O -> 메모리 할당
- 메모리 X -> CPU 스케줄러로부터 CPU소유권이 넘어오기 전까지 대기
대기 중단 상태
- ready suspended -> 메모리 부족으로 일시 중단
실행 상태
- running -> CPU 소유권 + 메모리 핟당 -> 인스트럭션(instruction, 교사(컴퓨터)에 의해 수행되는 교육(것)) 수행 중
중단 상태
- blocked -> 이벤트 발생! -> 프로세스 잠시 중지
일시 중단 상태
- blocked suspended -> 중단 상태에서 다시 시작할려 했지만, 메모리 부족으로 다시 중지
종료 상태
- terminated
- 자발적 중지 -> CPU, 메모리 소유권 놓고 끝
- 비자발적(abort) 중지 -> 부모 프로세스가 자식 프로세스 강제중지
- 자식 프로세스가 할당된 한계치 OVER
3. 프로세스의 메모리 구조
스택
- 동적인 특징
- 지역변수, 매개변수, 함수 -> 컴파일 시 크기가 결정
- 스택과 힙은 메모리 영역이 겹치면 안됨 -> 2 사이를 비워 놓음
힙
- 런타임 시 크기가 결정
- 동적인 특징
데이터 영역
- 전역 변수, 정적 변수
- BSS
- 초기화 되지 않는 변수가 0으로 초기화 되어 저장
- Data
- 0이 아닌 다른 값으로 할당된 변수들이 저장
코드 영역
- 프로그램에 내장되어 있는 소스 코드가 들어가는 영역
- 기계어로 저장(수정 불가능) -> 정적
4. PCB(Process Control Block)
- 프로세스에 대한 메타 데이터(데이터에 관한 구조화된 데이터이자 데이터를 설명하는 작은 데이터)를 저장한 것
- 일명 프로세스 제어 블록
- 따라서 프로그램 생성 -> 프로세스 생성 -> 프로세스 주소 값들이 스택, 힙에 저장 -> 운영체제가 프로세스의 PCB 생성
- 메타데이터(힙, 스택, 메모리...)가 PCB에 저장되어 관리
- 중요한 정보들이기 때문에 접근하지 못하도록 커널의 가장 앞부분에서 관리
컨텍스트 스위칭(싱글 코어 기반)
- PCB 교환 과정
- 여러가지를 동시에 하는 것처럼 보이지만, 빠른 속도로 스위칭을 하고 작업을 하는 것
5. 멀티프로세싱
- 동시에 2가지 이상 하는 것
웹 브라우저
- WEb browser -> 멀티 프로세스 구조
(a) Browser process
- 최상위 프로세스로, 다른 프로세스들을 조율합니다. 주소 창 및 이동 버튼을 포함한 어플리케이션의 크롬 부분을 제어하고, 네트워크 요청 및 파일 엑세스와 같은 웹 브라우저의 권한이 부여된 보이지 않는 부분을 제어합니다.
(b) Renderer process
- 웹사이트가 디스플레이 될 때 탭 안의 모든 것을 담당합니다. 다수의 프로세스가 생성되어 각 탭마다 할당되는데, 최근까지 크롬은 각 탭마다 별도의 프로세스를 할당하였지만 현재는 iframe을 포함하여 각 사이트별로 프로세스를 가지도록 변경되었습니다.(사이트 격리)
(c) Plugin process
- 웹 사이트의 플러그인(일반적인 소프트웨어의 일부. 웹 브라우저의 일부 기능들을 쉽게 설치하여 사용하게 할 수 있는 프로그램을 말한다.) 제어
(d) GPU process
- GPU를 활용해 회면을 그리는 부분 제어
IPC(Inter Process Communication)
- 프로세스 끼리 데이터를 주고 받고 공유 데이터를 관리하는 메커니즘
(a) 공유 메모리
- 여러 프로세스에 동일한 메모리 블록에 대한 접근 권한이 부여되어 프로세스가 서로 통신할 수 있도록 '공유' 버퍼를 생성하는 것
(b) 파일
- 디스크에 저장된 데이터 또는 파일 서버에서 제공한 데이터를 의미(다른 곳에서 온 데이터)
(c) 소켓
- 다른 프로세스나 네트워크의 다른 컴퓨터로 네트워크 인터페이스(규율)을 통해 전송되는 데이터 TCP, UDP 있음
(d) 익명 파이프
- FIFO
- 자식 프로세스와 부모 프로세스 사이에서만 사용 가능
(e) 명명된 파이프
- 파이프 서버와 하나 이상의 파이프 클라이언트 간의 통신을 위한 단방향 또는 이중 파이프
(f) 메시지 큐
- Queue
- 공유메모리(IPC)를 구현하면 동기화가 높아짐 -> 복잡..
- 대안으로 메시지 큐 사용
6. 스레드와 멀티스레딩
스레드
- 프로세스의 실행 가능한 가장 작은 단위
- 프로세스는 힙, 스택, 데이터, 코드 모두 각각 생성
- BUT 스레드는 스레드 끼리 공유
멀티스레딩
- 멀티스레드 -> 여러 thread로 구성된 process(1)
- 멀티 스레딩 -> 멀티스레드를 기반으로 처리하는 기법(2)
- 메모리 공유(+ 공간 효율성) (- 서로 영향이 감)
- 동시성(+ 순서)
7. 공유 자원과 임계영역
공유자원(shared resource)
- 시스템 안에서 각 프로세스, 스레드가 함께 접근할 수 있는 자원이나 변수 의미
- 공유자원을 2개 이상의 프로세스가 동시에 사용 -> race condition -> 접근 타이밍, 순서가 결과값에 영향주는 상태
임계영역(critical section)
- 둘 이상의 프로세스, 스레드가 공유 자원에 접근할 때 순서등의 이유로 결과가 달라지는 '코드영역'
- 해결법 3가지
- 상호 배제(1명만 임계 영역 사용가능)
- 한정 대기(특정 프로세스는 영원히 임계 영역에 들어가지 못하면 안 된다.)
- 융통성(다른 프로세스 방해 X) (만족)
(a) 뮤텍스(mutex)
- 프로세스, 스레드가 공유자원 lock()하고 사용 후, unlock()을 통해 잠금 해제하는 '객체'
- 공유된 자원의 데이터를 여러 '쓰레드'가 접근하는 것을 막는 것!
(b) 세마포어(semaphore)
- 공유된 자원의 데이터를 여러 '프로세스'가 접근하는 것을 막는 것
8. 교착 상태(deadlock)
- 2개 이상의 프로세스들이 서로가 가진 자원을 기다리며 중단된 상태
- 서로가 원하는 리소스가 같은 상태
교착 상태의 원인
(a) 상호배제
- 한 프로세스가 자원 사용 -> 다른 프로세스 접근 불가능
(b) 점유대기
- 특정 프로세스가 점유한 자원을 다른 프로세스가 요청한 상태
(c) 비선점
- 다른 프로세스의 자원 강제로 못 가지고 옴
(d) 환형대기
- A B -> 서로가 서로의 자원을 요구하는 상황
교착 상태의 해결 방법
- 자원을 할당할 때, 조건이 성립 안되도록 설계(힘듬)
- 교착 상태 가능성이 없을 때만 자원 할당, 교착 상태가 있으면 자원 할당 여부를 파악 하는 '은행원 알고리즘'
- 교착 상태 발생하면 사이클 찾기 -> 관련된 프로세스 제거
- 교착 상태 해결비용 높음 -> 사용자 작업 종료
https://velog.io/@seorim0801/%EC%9D%80%ED%96%89%EC%9B%90-%EC%95%8C%EA%B3%A0%EB%A6%AC%EC%A6%98
참조
https://hyuntaekhong.github.io/blog/OperatingSystem02/
https://velog.io/@danmin20/%EB%AA%A8%EB%8D%98-%EC%9B%B9-%EB%B8%8C%EB%9D%BC%EC%9A%B0%EC%A0%80-%ED%81%AC%EB%A1%AC-%EB%B8%8C%EB%9D%BC%EC%9A%B0%EC%A0%80-%EB%9C%AF%EC%96%B4%EB%B3%B4%EA%B8%B0
http://www.tipssoft.com/bulletin/board.php?bo_table=story&wr_id=13616
https://velog.io/@jsb12302/%ED%94%84%EB%A1%9C%EC%84%B8%EC%8A%A4%EC%99%80-%EC%8A%A4%EB%A0%88%EB%93%9C2
https://velog.io/@jsb12302/%ED%94%84%EB%A1%9C%EC%84%B8%EC%8A%A4%EC%99%80-%EC%8A%A4%EB%A0%88%EB%93%9C2
https://wooody92.github.io/os/%EB%A9%80%ED%8B%B0-%ED%94%84%EB%A1%9C%EC%84%B8%EC%8A%A4%EC%99%80-%EB%A9%80%ED%8B%B0-%EC%8A%A4%EB%A0%88%EB%93%9C/
https://wooody92.github.io/os/%EB%A9%80%ED%8B%B0-%ED%94%84%EB%A1%9C%EC%84%B8%EC%8A%A4%EC%99%80-%EB%A9%80%ED%8B%B0-%EC%8A%A4%EB%A0%88%EB%93%9C/
https://m.blog.naver.com/swanm13/221970189218
https://sycho-lego.tistory.com/11
https://hoyeonkim795.github.io/posts/%EA%B5%90%EC%B0%A9%EC%83%81%ED%83%9C%EC%9D%98-%EA%B0%9C%EB%85%90%EA%B3%BC-%EB%B0%9C%EC%83%9D%EC%9B%90%EC%9D%B8/
https://www.crocus.co.kr/1364
.
