diff --git a/operating-system/context-switch/han/README.md b/operating-system/context-switch/han/README.md new file mode 100644 index 0000000..5fac1af --- /dev/null +++ b/operating-system/context-switch/han/README.md @@ -0,0 +1,96 @@ +# Interrupt + +- 프로세스가 하던일을 멈추고, *이미 정해진 코드*에서 요청에 대한 처리를 **수행**하는 것. +- 각 자원들이 능동적으로 자신의 상태 변화를 CPU에게 알리는 방식. + +- `Polling` + - *CPU*가 일정한 시간 간격을 두고, 각 장원들의 상태를 주기적으로 확인하는 방법 + - Interrupt는 자원들이 CPU에게 자신의 상태를 알리는 방법이고.. +- 인터럽트는 하드웨어, 소프트웨어 인터럽트로 나눌수 있을듯. + - 하드웨어는.. 모니터 마우스 등등이고.. + - 소프트웨어는 CPU 자신이 인터럽트를 사용하는 경우 인듯. + + + +- Interrupt가 실행되는 과정 + + ![image](https://user-images.githubusercontent.com/22140570/136755289-4b270209-cbc6-4250-8070-1e76658b5c5d.png) + + - PC ? + - CPU가 실행하는 명령어 + - 레지스터에 있음 + + 2. 장치 (키보드) 의 인터럽트 발생 + + 3. 현재 실행 중인 프로세스 정보 저장 + 1. 어디에? 시스템 스택에. + 2. 어떤 정보? PSW(Program status Word, 현재 상태 정보), PC 레지스터의 값 (CPU가 어떤 명령어를 실행하고 있었는지 ) + + 4. Interrupt Vector에 가서, 요청들어온 인터럽트에 대한 ISR을 찾음. + + 5. 찾은 ISR에 대한 주소를 PC에 넣음 (인터럽트 처리를 위해서..) + + 6. 인터럽트 처리 + + 7. 저장된 프로세스 정보를 가져와서, 이 전 실행 되었던 프로세스 실행으로 돌아감 + +- 참고 키워드 + - Interrupt Service Routine, ISR (Interrupt Handler) + - Interrupt Vector + - 여러가지 인터럽트들을 관리하는 테이블 + + + +# Context switching + +- 위 이미지에서 (3,4,5)번 과정 + +- 하나의 프로세스가 cpu를 사용하는 상태인데, 다른 프로세스가 cpu를 사용하게 하기 위해서... 발생하는 것. + + - 즉 이전 프로세스의 상태를 **보관** 하고, 새롭게 실행된 프로세스의 상태를 **적재하도록 하는 과정**, 작업을 의미. + +- 과정 + + ![image](https://user-images.githubusercontent.com/22140570/136755834-7938b4ae-86bb-408e-8cb4-ee7fc909435a.png) + + - 인터럽트 과정과 같음 + + 1. P0 실행 중.. 그런데 P1 프로세스에서 인터럽트 or 시스템 콜 발생 + 2. P0 프로세스에 대한 정보를 PCB에 저장. 그리고 P1에 대한 정보를 PCB에서 찾아서, 메모리에 올림 + 3. P1 실행 + 4. 위 반복. + + + +- Context Switching이 왜 발생? + - CPU는 한번에 하나의 프로세스만 처리할 수 있기에. + - 여러 프로세스를 실행, 중단 하면서 작동하기에. + - 이 비용이 비싸기에, Mutil Thread 환경이 나오지 않았을까 + + + +- 참고 키워드 + - idle : CPU가 아무일도 하지 않는 상태 + - idle이 겹칠 경우를 오버 헤드라 말함. + - 왜? + - 필요한 정보들을 적재하느라, CPU가 아무일도 하지 않는 상태이기 때문에 (일을 안해서, CPU가 낭비되고 있음) + - 즉 프로세스가 많아지면, 적재과정 때문에 CPU가 안하는 일이 많아져서 오버헤드가 증가할듯. + - PCB (Process Control Block) + - 레지스터에 있고, Queue (LIFO) 구조임. + + - process state : 프로세스 상태 값 (Create, Ready, Runinng..) + + - procuess counter : CPU가 다음 실행할 명령어의 주소 값. + + + ![](https://nesoy.github.io/assets/posts/20181113/1.png) + + + +# 참고 + +- https://www.youtube.com/watch?v=-4HKhwlH3FQ +- http://www.kyobobook.co.kr/product/detailViewKor.laf?mallGb=KOR&ejkGb=KOR&barcode=9788993712476 +- https://nesoy.github.io/articles/2018-11/Context-Switching +- https://jeong-pro.tistory.com/93 + diff --git a/operating-system/deadlock/han/README.md b/operating-system/deadlock/han/README.md new file mode 100644 index 0000000..a9a175c --- /dev/null +++ b/operating-system/deadlock/han/README.md @@ -0,0 +1,157 @@ +# Deadlock이란? + +- 교착 상태 + +- 둘 이상의 프로세스가 각자가 가지고 있는 자원을 보유한 채, 외부 조치 없는 한 영원히 그 상태에서 기다리고 있는 상황을 의미. + + - 즉 어떤 자원을 가지고 있고 + 무슨 이유에서 인지, 외부 조치 없이는 무조건 기다리게 되어있는 상황을 의미 + + + +## 실제 시스템에서 교착 상태 + +- Database (MySQL) + + - **상호 거래 패턴** + + ![image](https://user-images.githubusercontent.com/22140570/136698857-2e340bae-151d-47fa-85a1-c22c007c8f0e.png) + + - 트랜잭션 1 은 A를 점유하고 있음., 트랜잭션 2는 B를 점유하고 있음. + - 이 상태에서 트랜잭션1 는 B에게 접근하려 함 (이미 트랜잭션 2가 점유하고 있는 상태) + - 그런데 트랜잭션 2은 A에 접근하려 함 (이미 트랜잭션 1이 점유하고 있는 상태임) + - 점유가 풀려야, 해당 데이터에 접근할 수 있는데, 현재 상태로 보아서, 점유가 풀릴 수가 없는 상태임. (교착 상태) + + + +## 교착 상태를 만족하기 위한 4가지 필요조건 + +- 아래 4가지 조건은 만족하게 되면, 교착 상태에 빠지게 된다. + - 아래 4가지 중에 하나만이라도 생기지 않도록 할 수 있다면, 교착 상태는 절대 발생하지 않는다. + + + +### 상호 배제 조건 + +> *mutual exclusion condition* + +- 자원의 배타적인 사용이라 부르기도 함. + +- 한번에 프로세스 하나만 해당 자원을 사용할 수 있음. + - 다른 프로세스가 위 자원을 사용하려 하면, 기다려야 한다. + - 한정된 자원에 대한 프로세스들의 사용 경쟁을 의미. + + + +### 점유와 대기 조건 + +> *hold and wait condition* + +- 자원의 부분 할당이라 부르기도 함. + - 각각의 프로세스는 자신의실행 전체 과정에서 자원이 필요할 때 마다, 일부분을 확보, 실행해나가다가, 할당 불가능한 자원 때문에 교착 상태에 빠진다. + +- 즉 프로세스는 자원을 최소한 하나 보유하고, 다른 프로세스에 할당된 자원을 위해 대기하는 프로세스가 존재함을 의미. + + + +### 비 선점 조건 + +> *nopremption condition* + +- 자원의 선점 불가능성이라 부르기도 함. + +- 이미 할당된 자원을 강제로 뻈을수는 없음 + - 즉 자원의 선점 불가능성을 고수하는 경우, 해당 조건 때문에 교착 상태를 일으키는 조건을 만족하게 되기도 함. + + + +### 순환 대기 조건 + +> *circular wait conditon* + +- 대기 프로세스의 집합이 순한 형태로 자원을 대기 + + + + + +## 교착 상태 해결 방법 + +### 예방 + +- 위 4가지 발생 조건 중에, 하나라도 발생하지 않도록 하는 것. +- 예를 들면.. + - 상호 배제 조건 의 경우, **여러 프로세스** 들이 해당 자원을 사용할 수 있도록 해주는 것. + - 다만, 배타적으로 사용할 수 밖에 없는 자원도 있기에, 상호 배제 조건을 배제하는건 불가능할듯. + - 점유와 대기 조건의 경우, 자원이 부분할당 되지 않고, 필요한 자원을 모두 할당해 버리는 것. + - 자원의 낭비 발생. 심각하게.. + - 비 선점 조건의 경우, 모든 자원이 선점 가능하도록 해주는 것. + - 즉 어떤 자원을 A 프로세스가 잡고 실행 중에 있는데, B 프로세스 에서 해당 자원을 요청할 경우, A프로세스는 자신이 보유하고 있는 자원을 내놔야함. + - A 프로세스 입장에서는.. 잘 하고 있는 도중 자신의 일의 결과를 모두 뺏길 수 있음 (중단 혹은 다시 시작 가능성 있으므로.) + - 자원 낭비 + - 순환 대기 조건을 배제하는 경우, 자원의 요청 순서를 단 방향으로만 하도록 하는 것일듯. + - 그래도 자원 낭비, 무한 대기는 피해갈 수 없을듯. (모든 경우의 수를 따질 수 없으므로) + + + +### 회피 + +> *Safe sequence, Safe state* + +- 교착 상태를 피해가게 하는 방법 + +- 안전 상태? + - 프로세스들이 요청하는 모든 자원을, 교착 상태에 빠지지 않으면서 모두에게 자원을 할당해줄 수 있는 상태 +- 안전 순서? + - 특정 순서로 프로세스들에게 자원을 할당해줬더니, 교착 상태가 발생하지 않았음. 이러한 순서. +- 불안전 상태? + - 안전 상태가 아닌 상태 + - 교착 상태 발생 가능성이 있다. + +- 은행원 알고리즘 + + - 시스템을 안전 / 불안전 상태로 구분 + - 불안전 상태이면, 할당할 자원을 고정, 프로세스 수도 고정, 제한된 시간안에 자원 반납등의 조건이 전제됨. + +- 회피 전략을 즉 자원을 요청할 때마다, 시스템의 안전 상태를 파악해야함 (오버헤드 심함) + + - 이러한 점 때문에, 해당 전략을 사용하는 시스템은 거의 없다. + + + +### 탐지 및 복구 + +- 교착 상태가 자주 발생한다면 사용. +- 교착 상태는 **필요악** + - 왜? + - 교착 상태는 안 만들어지는게 좋지만, 교착 상태가 발생할 수 없는 환경을 만들어 버린다면, 할당된 자원을 효율적으로 사용하는 것은 불가능한 일이 됨. +- 탐지 + - RAG Resource Allocation Graph + - 자원 할당 그래프. + - 교착 상태 탐지를 위해, 현 시스템의 상황을 나타내는 그래프임. + - Allocation, Request, Available + - **순환 대기 조건**이 존재하는 지 탐지함 (시스템의 자원 상태를 확인함) + - 탐지 알고리즘을 사용..해서 오버헤드 존재 +- 복구 + - 순환 대기를 깨서, 교착 상태로 부터 회복하도록 함. + - 순환 대기에 포함된 **프로세스의 제어권을 뺏고 롤백**.. 혹은 순환 대기가 깨질 때까지 **프로세스 종료** + - 전자 최소 비용의 프로세스를 고를 수 있지만, 이를 계산하는 데 복잡 + - 후자 프로세스를 종료할 때 마다, 교착 상태가 해결 되었는지 확인해야함 (오버헤드) + - 어떤 프로세스를 깰까? + - 시스템마다 다른 기준으로 우선 순위 + - MySQL의 경우, 트랜잭션의 크기가 가장 작은.. + +### 무시 + +- 교착 상태가 드물게 발생한다면 이 방법을 사용 +- 드물게 발생하는데, 굳이 교착 상태 해결 비용을 미리 지불할 필요는 없을듯. +- 즉 교착 상태가 발생했다? 그러면 사용자가 원인이 되는 프로세스, 스레드를 죽이는 방법을 택함. + + + +# 참고 + +- https://www.youtube.com/watch?v=FXzBRD3CPlQ + +- https://chanhuiseok.github.io/posts/cs-2/ +- http://www.kyobobook.co.kr/product/detailViewKor.laf?mallGb=KOR&ejkGb=KOR&barcode=9788993712476 +