티스토리 뷰
* 이 글은 coursera에서 제공되는 HW/SW Interface 강의를 요약한 내용입니다.
Process란 뭘까? 이 개념에 접근하기 전에 우리가 실행하길 원하는 프로그램들이 컴퓨터 내에서 어떻게 동작하는지를 살펴봐야 한다. 프로그램은 일종의 instruction을 모아둔 집합체이다. 우리가 프로그램을 만들기 위해서 high level language로 구현하는 코드들 역시 컴파일러를 거치게 되면 list of instruction set이 되게 된다. 그런데 단순히 이값이 변환되기만 해서는 프로그램이 실행되지 않는다. 정말로 프로그램을 실행하길 원한다면 해당 instruction들을 memory에 load를 시켜야한다. 막연하게 올려야 된다가 아니고 이렇게 프로그램과 CPU에서 Memory까지 실행에 주체가 되는 것들간의 interface를 제공하는 것이 process가 된다.
결국 다르게 이야기 하면 process가 있어야 프로그램이 실행될 수 있고, 이말은 즉 process라는게 program을 실행시키는 instance라고도 표현할 수 있다. 그래서 이걸 실행시키는 하드웨어가 processor가 되는 것이다. 지난 포스트에서도 언급한 것처럼 process는 실행되는 동안 program 혹은 system의 state를 바꿀 수 있기 때문에 자체적인 control flow를 가지고, 자신만의 memory space를 가진다.
그런데 여기서 잠깐 고민해봐야 할 게 만약 이런 process들이 여러개가 동시에 실행될때는 과연 어떻게 될까하는 점이다. 다음과 같은 예시가 있다.
위의 이미지는 process A, B, C의 entry point와 end point를 표시한 것이다. process 중간에 보면 아무것도 없는 영역이 존재하는데 이것은 process A가 끝났다는 것이 아닌, 다른 process의 수행을 위해서 해당 process의 수행을 멈췄단 뜻이다. 결국 process A의 수행시간동안에는 Process B도 수행되었다고 할 수도 있고, 혹은 C도 수행되었다고 할 수 있다. 이걸 동시에(concurrent) 하게 수행되었다고 한다. 일반적인 사람이 보기에는 A 와 B가 어떻게 동시에 실행되었냐는 의문을 가질 수 있다. 엄연히 말해서는 이는 동시에 했다고 하기 힘들겠지만 process 입장에선 instruction execution이 해당 시간내에 overlap된 경우를 보통 concurrent 하다고 이야기 한다. 그림으로 표현하면 다음과 같이 되는 것이다.
반대로 B와 C의 경우는 overlap이 되지 않았으므로 concurrent가 아닌 sequential execution이 일어났다고 할 수 있다. 이렇게 판단하는 이유는 CPU 자체가 한번에 한 instruction만 수행할 수 있기 때문이다. 물론 지금 가정은 single thread에서 process 3개가 돌때를 가정하는 것이다. 당연히 multi processor 입장에서는 동작이 조금 달라지게 된다.
그러면 한개의 processor에서 여러개의 process가 돌때, 그것도 동시에 돈다고 생각할때 어떻게 동작할까? 아까 말한것처럼 process는 일종의 program을 돌리는 instance라고 했고, program자체는 instruction의 list이다. 그리고 자체의 control flow를 가진다. 그럼 앞의 사진처럼 Process A에서 B로 이동하는 것도 일종의 control flow를 바꿔주는 상황이라고 볼 수 있다. 또 B가 끝난 후에는 다시 A로 돌아가 A process를 수행해야 된다. 어떻게 보면 지난 포스트에서 다뤘던 exception mechanism과 개념이 비슷한데 이렇게 process내에서 control flow를 바꿔주는 동작을 context switching이라고 한다. 이 개념은 cpu 입장에서 보면 조금 이해가 쉬울 듯하다. cpu 입장에선 앞에서도 언급했던 것처럼 한번에 한 instruction만 수행되고, 이 instruction의 집합이 program이 된다. 그럼 이 프로그램이 돌아갈때의 cpu에 들어있는 state register(context)들은 모두 그 프로그램만의 것이고, 이게 만약 다른 process로 전환될 경우에는 현재의 state register를 그 프로그램의 state register로 switching해야 될것이다. 이런 맥락에서 context switching을 이해하면 좋지 않을까 싶다.
보통 이런 context switching의 주체는 kernel이 되는데 kernel은 독립적인 process가 아니라 일종의 priviliege level이라고 보면 좋을 거 같다. 보통 이때 system state를 handling할 수 있는 권한이 생기는데 이때 context switching이 발생한다. 위의 이미지에서 Process A와 B간의 Context switching을 표현한 그림이 아래와 같다.
이렇게 kernel code가 실행되는 동안, 다른게 말하면 kernel priviliege가 있는 시간동안 process는 자신의 현재 state를 저장하고 다른 process로 control을 넘겨주게 된다. 그리고 해당 process가 종료되면 save된 state를 다시 restore하는 과정을 거치게 되는데 보통 이때 필요한 context는 당연히 해당 instruction을 수행하고 있는 지점을 표현해주는 instruction pointer가 있겠고, 만약 뭔가 opcode가 돌고 있었다면 그걸 담고 있던 general purpose register나 special purpose register 역시 context의 하나가 될 것이다.
사실 지금 연구실에서 하고 있던 연구의 핵심이 이 context switching을 이용한 것이었다. 지금은 이미 다 구현하고 잘 돌아가고 있긴 하지만, 이렇게 기본적인 기능을 이용하면 core를 virtualize할 수도 있는것이고 혹은 어딘가로 이동시킬 수도 있다. 언제 연구내용이 마무리되면 이 부분에 대해서도 간단하게 소개해보고자 한다.
'Study > OS' 카테고리의 다른 글
[Memory] Indirection (0) | 2014.09.01 |
---|---|
[Process] Fork-exec Model (0) | 2014.08.29 |
[Process] Creating New Processes (0) | 2014.08.29 |
[Process] Exceptional Control (0) | 2014.08.28 |
[Memory] Memory Consideration in OS (0) | 2013.11.26 |
[OS] Context Switch (0) | 2013.06.29 |
[OS] POSIX Thread (0) | 2013.06.25 |
- Total
- Today
- Yesterday
- dynamic programming
- Gan
- 파이썬
- 딥러닝
- Pipeline
- DepthStream
- TensorFlow Lite
- bias
- Kinect
- PowerPoint
- Distribution
- 강화학습
- 한빛미디어
- Expression Blend 4
- ColorStream
- reward
- Kinect SDK
- Offline RL
- SketchFlow
- Policy Gradient
- Windows Phone 7
- RL
- Variance
- processing
- Off-policy
- arduino
- End-To-End
- ai
- windows 8
- Kinect for windows
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |