차마시는 개발자

### Deadlock avoidance ### : 운영체제에게 자원 요청이 들어오면 자원을 할당해주었다고 가정한 상태에서 잠재적으로 Deadlock이 일어나는지 유무를 판단하여 Deadlock이 일어난다면 자원이 충분함에도 불구하고 할당해주지 않는 방법 ​ : 운영체제에게 미리 정보를 알려줘야 한다. (thread 에게 리소스를 얼마나 할당할지를 정해준다) ​ ​ ​ : thread들이 리소스 사용 상황을 봤을 때 최악의 상황(모든 thread가 한 번에 다 리소스를 요청)을 감안하더라도 그리고 각 thread들이 사용 예정일 리소스를 사용하더라도 Deadlock이 되지 않는다. => 모든 thread가 요청하는 리소스 양을 봤을 때 모든 thread를 다 만족 시켜줄 수 있다 => safe seque..

### Handling Deadlocks ### • Deadlock ignorance. : Deadlock의 발생 빈도가 낮은 경우 사용 ​ • Deadlock prevention. : 처음부터 Deadlock 이 발생을 막는 것(Deadlock이 발생 전의 조치) ​ • Deadlock avoidance. : Deadlock을 좀 더 정교하게 피하는 방법 ​ ​ ​ ​ ### Deadlock prevention ### : 이 4가지 조건을 만족 해야 Deadlock 발생!!! ​ 1. : 이 체계를 통해 여러 thread가 공통 리소스를 동시에 공유할 수 있다. (이 공유 리소스에는 한번에 1개의 thread만 ) ​ : 실용적이지 않다...

### Resource Allocation Graph ### : Graph는 V: vertices, E: edges(link, 연결성), node 로 구성) ​ : Request edge => thread 가 리소스(여러개 가능)를 요청하고 대기하는 상황) ​ : Assignment edge => 구체적인 리소스가 요청 thread에게 실제 할당되는 연결성 1. : graph내에서 사이클이 존재 할때 deadlock을 발생시킬 수 있는 risk가 있다 (circular wait과 관련) : 리소스에서 instance가 여유가 있으면 deadlock 발생 하지 않는다(hold and wait관련) 2. : T3랑 R2사이에 Request edge가 되어 있는 상태입니다. 그래서 2개의 사이클이 존재하고 있..

### Deadlock이 발생할 수 있는 Condition ### : 4가지 조건 만족 할때 Deadlock이 된다. ​ 1. : 하나 이상의 리소스를 공유 할 수 없는 모드로 유지해야 한다 (동시에 접근 할 수 없는 상태) ​ 2. : thread는 하나 이상의 리소스를 보유하고 다른 thread가 보유한 추가 리소스를 얻기 위해 대기한다. => 최소 2개 리소스를 요구하는 thread가 하나는 가지고 있고 다른 리소스를 기다리고 있는 것 ​ 3. : 자기 의지와 상관 없이 thread가 리소스를 빼앗기면 안된다는 것 (자원을 선점 할 수 없다) ​ 4...

### Deadlock ### : process가 자원을 얻지 못해 다음 처리를 하지 못하는 상태로, '교착 상태'라고도 하며 시스템적으로 한정된 자원을 여러 곳에서 사용하려고 할때 발생합니다. => 두개 이상의 thread가 동작할 때 thread가 무한 대기 상황 ​ 1. 병렬/병행 일때 2. 자원이 유한할 때 ​ ​ ​ 1. : Thread가 리소스를 요청할 때 요청을 즉시 할당 할 수 없는 경우 요청 스레드는 자원을 확보 할 때까지 기다려야 한다. ​ 2. : Thread는 리소스에서 작동할 수 있다 (ex. 리소스가 mutex lock인 경우 thread는 critical section에 접근 할 수 있다) ​ 3. : Thread가 작업..

### Dining Philosophsers Problems (철학자들의 만찬문제) ###​ : Deadlock(교착)상태를 설명하기 위한 문제 ​ 5명의 철학자가 원탁에 앉아서 식사를 한다. 철학자들 사이에는 포크가 하나씩 놓여 있고, 철학자들은 다음의 과정을 통해 식사를 한다. (꼭! 포크 2개를 들고 밥을 먹어야한다) ​ 1. 왼쪽 포크가 사용 가능해질 때까지 생각을 한다. 만약 사용 가능해지면 집어든다. 2. 오른쪽 포크가 사용 가능해질 때까지 생각을 한다. 만약 사용 가능해지면 집어든다. 3. 양쪽의 포크를 잡으면 정해진 시간만큼 식사를 한다. 4. 오른쪽 포크를 내려놓는다. 5. 왼쪽 포크를 내려놓는다. 6. 다시 1번으로 돌아간다. ​ ​ 간단하게, 만약 모든 철학자(proces..

### Readers and Writers Problem ### : database에서 공유데이터에서 접근하는 여러개의 concurrent processes(writers, readers)가 있다. ​ : writer process가 공유 데이터에서 데이터를 수정할 때 다른 concurrent process가 들어오면 data consistency에 문제 발생 ( 같은 시간에 예방책 => 공유 데이터을 critical section으로 해두고 mutual exclusion을 하여 data inconsistency를 예방한다 ) : Reader - data set만 읽을 수 있지만 update 할 수 없다 : Writer - shared data를 읽고 쓸 수 있다 int read_count = 0; //..

### Bounded Buffer Problem ### : 유한 buffer 문제 ​ : 생산자와 소비자 문제(생상자가 data를 buffer에 넣고 소비자가 buffer에서 data를 읽는다) ​ : pool/buffer cache (1개의 buffer에는 1개의 item을 저장할 수 있다) ​ int n; // mutual exclusion을 해결하기 위한 semaphore 변수들 semaphore mutex = 1; //lock 담당, 제공하는 역할 semaphore empty = n; //buffer 상태 semaphore full = 0; //buffer 상태 // producer process while (true) { // next_produce에서 item 생성 wait(empty); wa..