프로그램의 실행 (메모리 load)
프로그램이 메모리에 올라가기전에 virtual memory가 생긴다 그리고 각 프로세스들은
stack (함수안의 지역변수들) -> 함수 호출과 리턴은 스택에 쌓아 놨다가 사라졌다가한다.
data (메모리 데이터들,)
code (프로그램 코드들이 올라간다, 컴파일하여 변환된 기계어들)
영역을 가지게된다.
커널의 주소 공간
- 운영체제의 stack , 각 프로세스마다 별도로 두고있다
- 왜냐? a라는 프로세스가 실행하다가 디스크파일을 읽어야할 상황이 오게 되면 본인이 하지 못하기에 시스템콜을 해야하는 상황이 있다 그럴때 stack에는 프로세스a의 커널 스택에 쌓이게 된다.
- pcb는 프로세스의 실행하는데 필요한 정보들 담겨져있다 cpu 우선순위 메모리할당.. 등등....
프로그램의 실행
- 프로그램이 실행할때는 유저모드 커널모드 갔다가 왔다가한다 사용자 정의 함수나 라이브러리를 사용할때는 유저모드이지만 systemCall이 발생할때는 kernelmode로 돌아가면서 os에게 돌아간다
프로세스의 개념
- 공룡책에 적혀있는 유명한 말 "Program is a program in execution"
- 프로세스 context라는 말이 많다 process context이란 현재 프로세스의 상태를 나타내는 것이다 (메모리를 얼마나 가졌는가?, 과거에 cpu를 얼마나 사용하였는가?, ..)
- 프로세스를 살아있는 생명으로 봐도된다 -> 하나의 생명은 그때 그때마다 상태가 다른데 이것을 프로세스의 context라고한다
- 위 그림에서 I/O작업들을 수행하기 위해서 IO queue에 들어가서 대기를 하다가 IO작업을 수행하게 된다. -> 작업 종료후 cpu를 o에게 전달을 해야하는데 그 과정은 프로세스가 cpu에게 instruction을 걸고 cpu 제어권이 다시 os에게로 돌아가게된다
cpu , 프로세스 상태
- cpu에서 일을 할려면 ready queue에 들어가있게된다 순서가 있으니..
- 프로세스 상태에서는 대표적으로 running, ready, blocked가 있다
- running
- cpu를 가지고 instruction을 수행중인상태
- running에서 있다가 상태가 변경되는 경우가 3가지정도가 있다
- timer가 다 되어서 다시 ready로 들어가는 경우
- 시간이 오래걸리는 io작업이 생길 경우
- 현재 수행할 일을 다 완료했을 경우
- ready
- cpu를 기다리는 상태
- 메모리를 주면 바로 실행가는한 상태
- blocked(wait, sleep)
- cpu를 주어져도 instruction을 수행할 수 없는 상태이다 예를들면 ready queue에 들어가 있는 상태이거나
- 위 사진에서 프로세스들끼리도 공유자원에 접근 할 수 있는데 그곳에는 여러 프로세스들이 동시에 접근을 하면 안되니 기다리는 상태도 blocked 상태이다...
- suspended (stopped)
- 외부적인 이유로 프로세스의 수행이 정지된 상태
- 중기 스케쥴러에의해서 프로세스의 메모리가 빼앗긴 상태
- blocked 상태와 suspended 상태의 사이는 suspended는 프로세스가 일을 하지 않는것이고, blocked는 메모리에 올라 가 있는 상태이긴하다.
- 예를들어 프로세스a가 프로세스를 실행하다가 io작업을 해야하는 경우 os에게 부탁하기 위해서 시스템콜을 하는 경우가 이런 경우에도 아직까지는 running상태라고 말한다 어차피 다시 커널에 있다가 해당 프로세스a에게로 돌아갈 것이기때문이다.
스케쥴러
- cpu는 한번에 여러개를 실행하지못한다 빠르게 각각을 실행하는 것이다, 예를 들면 유튜브, 카카오, 라인을 실행 시키기고 있을 때
유튜브를 조금 라인을 조금 짧게 짧게 실행을 시키는 것이다. - 스케쥴러는 어떤 프로세스에 대해서 레디큐로 보낼지 running할지 이런 상태들을 결정하는 것이다
- 스케쥴러에는 장기, 단기, 중기가 있는데 장기는 현재 사용을 하지않고 중기 스케쥴러의 역할에 대해서 설명해보겠습니다
- 여유 공간을 마련하기 위해서 프로세스에게서 메모리를 빼았는 것이 중기 스케쥴러 but 프로세스들에게 무조건 메모리를 주는 것은 장기 스케쥴러 ( 현대 프로그램에서는 장기 스케쥴러를 채택하지 않는다, 메모리에 올라 가있는 수를 조절 하기 위해서 swapper를 사용한다 (중기스케쥴러) )
process control block
- os가 각 process를 관리하기 위해서 가지고 있는 해당 프로세스들의 상태정보
- pid, process state, priority, register, pc, ..
context switch
- cpu를 한 프로세스에서 다른 프로세스에게로 넘겨주는 과정
- cpu가 프로세스에서 프로세스에게로 넘어가기 직전에 os는 a - > b프로세스로 cpu가 이동할때 a프로세스의 정보를 어딘가에 저장을 해놓아야한다 그래서 process의 정보를저장하기 위해서 process A의 pcb에 저장해 놓고 난후 process b의 pcb에 가서 이전에 실행했던 상태를 가지고 온 뒤 cpu제어권을 넘겨 받는다
- 문맥교환에서 조심할 것은 프로세스A에서 프로세스B로 cpu가 넘어야지 문맥교환이지 프로세스A에서 시스템콜을 해서 제어권이 커널에게 돌아가는것은 문맥교환이 아니다
- 밑의 그림에서 1보다 2에서 context switch가 일어나는 경우 오버헤드가 굉장히 크다 이유는 -> context switch가 일어나면 이전에 가지고 있던 프로세스들의 cahe memory를 다 지워줘야하기때문이다..
THread
- 프로세스 중에서 cpu 수행단위를 스레드라고한다.
- 스레드를 사용하면 병렬성을 높일 수 있다
- 다중 스레드가 일을 하면 높은 산출물을 낼 수 있다
- 스레드의 장점
- 즉각적인 방응이 있다 왜냐? 웹을 예시로 들면 스레드 a가 네트워크로 정보를 가지러갔을때 스레드b는 사용자에게 화면을 보여주도록 하면 좀더 지루하지않고 즉각적인 반응을 끌어낼 수 있다
- 자원을 공유한다 스레드는 공유자원을 가지는데 각각의 스레드는 stack영역이나 register를 제외하고는 자원을 공유한다
- 효과적이다 프로세스하나를 생성하는 것보다 수십배로 더 저렴하다
멀티스레에서 영역 공유
- 코드영역은 나눠쓸 수 있다,
코드영역을 나누고 흐름a, 흐름b가 있을 때 흐름은 함수호출을 한다 그러면 각기 stackㅇ여역을 가진다.
stack영역은 나눠서 가진다.
- stack영역도 같이 써야한다면?.. 만약 하나의 공간에 스택을 같이쓰면
ex
1. A프로세스에서 a1 호출
2. b프로세스에서 b1 호출
3. a프로세스에서 a2 호출, a3호출
이렇게 되면 a1 b2 a2 b3이 스택에 쌓이는데 b2를 쓸려면 a2 b3을 pop해야하는 현상이 발생한다
이러한 것이 불필요해서 stack영역은 따로쓴다..
코드는 같이 가지고 가고, stack은 각기 가지고 가면 굳이 자식 프로세스를 가지고가지 않아도된다. 여기서
나온 것이 쓰레드이다..
출처 : https://kouzie.github.io/operatingsystem/%ED%94%84%EB%A1%9C%EC%84%B8%EC%8A%A4-1/#pcb
'운영체제' 카테고리의 다른 글
세마포어, 뮤텍스 (0) | 2021.10.21 |
---|---|
프로세스 synchronize (0) | 2021.10.21 |
컴퓨터 시스템 구조 (0) | 2021.10.19 |
os란 (0) | 2021.10.18 |
address binding (0) | 2021.10.05 |