개인공부 후 자료를 남기기 위한 목적임으로 내용 상에 오류가 있을 수 있습니다.
경성대학교 양희재 교수님 수업 영상을 듣고 정리하였습니다.

다중 프로그래밍 환경에서…

• 부팅 직후 메모리 상태: O/S + big single hole

• 프로세스 생성 & 종료 반복 -> scattered holes(쪼개져있는 holes)

• 메모리의 단편화(Memory fragmentation):hole들이 떨어져있음
  • Hole들이 불연속하게 흩어져 있기 때문에 프로세스 적재 불가
  • 외부 단편화(extend fragmentation)발생: 홀들이 연속되어져있지 않고 떨어져 있음
    -> 흩어져 있는 메모리를 합쳐서 사용하면 새 프로세스를 올릴 수 있는데 연속되어 있지 않아 올릴 수 없는 불편함 존재(낭비)
  • 외부 단편화를 최소화 하려면?

외부 단편화를 최소화 하려면? = 연속 메모리 할당

• First-fit(최초 적합): 메모리를 순차적으로 찾아 제일먼저 발견되는 곳에 넣는 것
• Best-fit(최적 적합): 제일 사이즈가 밀접한 곳에 넣는 것
• Worst-fit(최악 적합): 크기가 제일 안맞는 곳에 넣는 것

• First-fit(최초 적합): 426은 넣을곳이 없음(외부 단편화)
• Best-fit(최적 적합): 다 넣을 수 있음(메모리를 제일 잘 사용한 방법)
• Worst-fit(최악 적합): 여전히 426은 들어가지 못함

할당 방식 성능 비교: 속도 및 메모리 이용률

• 속도면에서는 first-fit이 좋다 -> 제일 먼저 나오는곳에 넣으면 되니까
• 이용률: first-fit, best-fit -> 메모리가 얼마나 잘 이용되는가를 비교하자면 둘은 거의 비슷하게 나온다.

그러나 best-fit을 사용했음에도 불구하고 외부 단편화로 인한 메모리 낭비는 존재: 메모리의 1/3수준은 여전히 사용불가 수준

• Compaction: 메모리에 흩어진 hole들을 하나로 모은다. 최적 알고리즘 없음, 고부담(홀을 옮길지, 프로세스를 옮길지, 그 크기에 따라 굉장히 복잡함)
• 다른 방법은? Paging

페이징(Paging)

프로세스를 일정크기(=페이지)로 잘라서 메모리에 넣는다. (메모리를 일정한 단위로 잘라서 홀 안에 넣는다.)

• 프로세스는 페이지(page)의 집합
• 메모리는 프레임(frame)의 집합
• page의 사이즈와 frame의 사이즈는 똑같다. (해당 page는 각각의 frame에 들어가야 하니까)

페이지를 프레임에 할당한다

• MMU내의 Relocation register값을 바꿈으로써 cpu는 프로세스가 연속된 메모리 공간에 위치한다고 생각하게 한다.
• MMU는 페이지테이블(page table)이 된다.

일반적으로 프로세스를 잘라서 넣으면 프로그램은 실행이 되지 않는다. 이를 실행하기 위해서는 cpu를 속여야 한다.

cpu에 Relocation register를 여러개를 둠으로써 cpu는 연속으로 주소를 보냈다고 생각하지만, mmu를 거칠적에는 새로 연산을 해주게된다(다른 값을 내준다)
cpu는 여전히 메모리에 연속적으로 들어갔다고 생각하지만 실제 메모리에는 막 들어가져있다(다른 곳에 매핑 될 수 있도록 해준다)

사실은 메모리 전체를 처음부터 일정크기로 나눈다. 그리고 프로세스를 올릴 적에도 그냥 연속해서 올리는게 아니라 여러개의 페이지로 쪼개 올린다. 흩어져 잇음에도 불구하고 cpu를 속여 mmu값을 적절하게 넣어 연속적이게 보이도록 해준다. logical address는 연속, physical address는 불연속

이를 통해 메모리의 외부단편화 문제를 해결할 수 있게 된다.

페이징에서의 주소 변환(Address Translation)

• 논리주소(Logical address): cpu가 내는 주소
  • cpu가 내는 주소는 2진수로 표현(전체 m비트)
  • 하위 n비트는 오프셋(offset)또는 변위(displacement, d)
  • 상위 m-n비트는 페이지 번호(p)

이 전체중에 n을 몇비트로 할것인가는 페이지 사이즈를 얼마로 하는가에 따라 달라진다.
한 페이지 사이즈가 16byte라고 한다면 16byte단위로 자른다는것. 그렇다면 하위 n비트에 주어지는것은 4(2의 4승=16byte)비트이다.

• 주소변환: 논리주소 -> 물리주소(Physical address)
  • 페이지번호(p)는 페이지 테이블 인덱스 값(p=m-n)
  • p에 해당되는 테이블 내용이 프레임 번호(f)
  • 변위(d)는 변하지 않음

예제1) 논리주소 13번지는 물리주소 몇번지일까?

• page size = 4bytes
• page table: 5 6 1 2

예제2) 논리주소 3000번지는 물리주소 몇번지일까? & 물리주소 0x1A53번지는 논리주소 몇번지일까?

• page size = 1KB
• page table: 1 2 5 4 8 3 0 6

내부단편화, 페이지 테이블

• 내부단편화(Internal Fragmentation): 프로세스 크기가 페이지 크기의 배수가 아니라면, 마지막 페이지는 한 프레임을 다 채울 수 없다.
• 남는공간 ≠ 메모리공간

한 페이지의 사이즈는 4byte이고 프로세스의 크게는 15byte라고 하자. 그러면 4개의 페이지가 필요할 것이다.
즉 3번째 페이지는 전체를 다 채우지못하고 1이 남게될 것이다. 4의 배수가 아니니 한 프레임을 다 채울 수 없다. 이 1byte는 누구도 쓸 수 없는 영역이다.

이 또한 메모리의 낭비 이고 이런 경우를 내부단편화라고 한다.

-> 내부단편화의 크기는 미미하다. 크기의 최대 = 페이지사이즈 - 1byte

페이지 테이블 만들기

• CPU 레지스터로 만든다면?
  • 장점: 주소변환이 빠르다.
  • 단점: 많은 양이 들어가지 못한다.
• 메인 메모리로 만든다면?
  • 장점: 많은 양을 넣을 수 있다.
  • 단점: 주소변환이 느리다.

둘다 가능한 방법이지만, 현실적으로 사용하기에는 무리가 많다.

• TLB(Translation Look-aside Buffer): 별도의 s램 칩으로 만든다.

캐시메모리로 만든다. 메인메모리는 d램으로 만들어서 속도가 느린데, 캐시메모리는 s램으로 만들어서 속도가 빠르다.
s램으로 만드는데 캐시는 메인메모리에 있는애를 빨리 가져와서 접근하도록 하는데, 우리는 지금 주소변환을 위한 목적으로 만든것으로
이를 캐시라 하지않고 페이지테이블 목적으로 하이스피드 s램을 사용한것을 TLB라고 한다. 원리는 캐시메모리와 비슷하다.

cpu와 메모리 그 사이에 있는 TLB!

• 관점: 테이블 엔트리 개수 vs 변환 속도

• 연습> TLB사용 시 유효 메모리 접근 시간(Effective Memory Access Times)

  • 메모리에서 어떤 내용을 읽어오는데 걸리는 유효한 시간
  • Tm메모리를 읽는데 걸리는 시간 = 100ns, Tb look-aside Buffer를 읽는 시간=20ns, hit ratio=80%
  • h(Tb+Tm) + (1-h)(Tb+Tm+Tm) = 0.8(20+100) + 0.2(20+100+100) = 140ns

보호와 공유

보호(Protection): 해킹 등 방지
모든 주소는 페이지 테이블을 경유하므로, 페이지 테이블 엔트리마다 r,w,x 비트를 두어 해당 페이지에 대한 접근 제어 가능하다.

비트니까 0또는 1의 값을 가질 수 있을 것이고, 만약 r비트가 0인데 내용을 고치고 싶다고 하자.
그러면 page table에서 cpu에 interrupt가 가고, 그러면 cpu는 하던일을 중단하고 os의 특정 routine으로 가서 잘못된 행위를 하려는 프로세스를 강제로 종료시킨다.

이런 방식으로 해킹을 방지한다.

더 나아가, 어짜피 cpu가 내는 모든 주소는 page table을 경유하기 때문에 r,w,x비트를 두어 해당 페이지에 대한 접근 제어가 가능하다.
os가 설정해둔 권한 바깥의 일을 하려고 한다면, 인터럽트를 강제로 걸도록하여 막을 수 있다.

공유(Sharing): 메모리 낭비 방지
같은 프로그램을 쓰는 복수 개의 프로세스가 있다면 Code + data + stack에서 code는 공유가능
(단, non-self-modifying code = reentrant code(재 진입 가능 코드) = pure code인 경우) 프로세스의 페이지 테이블 코드 영역이 같은 곳을 가리키게 되어있다.

code 영역은 안바뀌고 data 영역만 변경된다. (data는 context switching이 이루어지지만 code는 같은곳을 가리킨다.)

개인공부 후 자료를 남기기 위한 목적임으로 내용 상에 오류가 있을 수 있습니다.
경성대학교 양희재 교수님 수업 영상을 듣고 정리하였습니다.

메모리 낭비방지

• Dynamic Loading
• Dynamic Linking
• Swapping

동적적재(Dynamic Loading)

loading: 어플리케이션(만들어진 실행파일)을 메인메모리로 올리는 것(적재하는 것)
프로그램 실행에 반드시 필요한 루틴/데이터만 적재

• 모든 루틴(routine, 함수, 프로시저)이 다 사용되는 것은 아니다(ex.오류처리)
• 모든 데이터(data)가 다 사용되는 것은 아니다(ex.배열)
• 자바: 모든 클래스가 다 사용되는 것은 아니다.
• 실행 시 필요하면 그때 해당 부분을 메모리에 올린다 cf. <->정적적재(static loading)

동적연결(Dynamic Linking)

여러 프로그램에 공통 사용되는 라이브러리(네트워크 관련된 라이브러리(ftp, 이메일..), printf.o 기계어코드 등..)

• 공통 라이브러리 루틴(library routine)을 메모리에 중복으로 올리는 것은 낭비
• 라이브러리 루틴 연결을 실행 시까지 미룬다
• 오직 하나의 라이브러리 루틴만 메모리에 적재되고 다른 애플리케이션 실행 시 이 루틴과 연결(link)된다. cf. <->정적연결(static linking)
• 공유 라이브러리(shared library, .so) - linux 또는,
• 동적 연결 라이브러리(Dynamic Linking Library, dll) - Windows

즉, 원래는 실행파일(exe file)을 만들기 전에 링크가 되는데(=정적연결), 링크를 미룬다. 일단 로드된 다음에(p1, p2가 메모리에 올라온 다음에) 링크를 한다.
p1과 p2 둘다 공통적으로 코드 내에 printf를 가지고 있다고 한다면, p1을 실행하려할 때 하드디스크에서 printf를 메인메모리에 가져온다. printf가 메모리에 올라오면 p1과 p2가 실행될때 그때그때 메인메모리에 있는 printf를 링크를 하여 사용한다.

Swapping

메모리에 적재되어 있으나 현재 사용되지 않고 있는 프로세스 이미지를 하드디스크의 특정부분으로 몰아냄
(컴퓨터 한참 사용하다가 중단하는 경우, 그때에도 내 프로그램은 여전히 메모리에 남아있는데 이 부분도 낭비이다.)

• 메모리 활용도를 높이기 위해 Backing store(swap device, 하드디스크의 일부) 로 몰아내기
• swap-out(몰아내기) vs swap-in(가져오기)
• Relocation register 사용으로 적재 위치는 무관
• 프로세스 크기가 크면 backing store 입출력에 따른 부담이 크다.

개인공부 후 자료를 남기기 위한 목적임으로 내용 상에 오류가 있을 수 있습니다.
경성대학교 양희재 교수님 수업 영상을 듣고 정리하였습니다.

메모리의 역사

• Core Memory: 반지모양 철심에 자석물질을 발라둬 전기가 흐르면 자석이 울리는 방식을 사용
• 진공관 메모리: 진공관 크기는 손가락 3~4개 정도
• 트랜지스터 메모리(반도체 칩안에 들어있는 소재 트랜지스터라고 함)-> 크기가 손톱만함, 1비트 저장하는데 4~6개가 들어감(많이 못넣음)
• 집적회로 메모리: SRAM(캐시메모리 만드는것), DRAM(메인메모리)

언제나 부족한 메모리

• 프로그램의 변천
  • 기계어/어셈블리어 작성 > C언어 작성 > 자바, 객체지향형 언어 작성을 하게되면서 프로그램의 크기가 커짐
  • 숫자 처리 > 문자 처리 > 멀티미디어 처리 > Big data 즉, 처리하는 자료도 커짐

• 메모리 용량 증가 vs 프로그램 크기 증가: 둘다 계속 증가! 언제나 부족한 메모리…!

• 어떻게 메모리를 효과적으로 사용할 수 있을까?
  • 메모리 낭비 없애기: 효과적으로 어떻게 사용할까?
  • 가상 메모리 (virtual memory): 실제 물리적인 메모리는 작은데, 크게 보이도록 가상의 메모리.

프로그램을 메모리에 올리기

• 메모리 구조: 주소(Address, 메모리의 입력) + 데이터(Data, 메모리의 출력)

• 프로그램 개발
  • 원천파일(Resource file): 고수준언어 또는 어셈블리언어
  • 목적파일(Object file): 컴파일 또는 어셈블 결과(하이레벨 언어를 기계어로 변환)
  • 실행파일(Executable file): 링크결과

• 컴파일러(compiler), 어셈블러(assembler), 링커(linker), 로더(loader)

• 프로그램 실행: code + data + stack(함수호출해서 돌아오는 주소 저장, 지역변수 저장)

• 실행파일을 메모리에 올리기
  • 메모리 몇번지에?
  • 다중 프로그래밍 환경에서는?
• MMU사용: 재배치 레지스터(Relocation register) > base/limit외에도 Relocation이 있음
  os가 Relocation register를 이용해 번지수를 지정(address translation)해줌으로써 실제 메인메모리 어디에 들어가있는지와는 상관없이 프로그램이 실행될 수 있도록 함
  
  • 그래서 메모리의 몇번지에 올리는지는 중요한 이슈가 아니다.
  • 프로그램 설계자가 처음 hwp를 만들때 번지를 0번지로 설정을 해놓았는데 hwp가 실제 1000번지에 있다면 프로그램이 실행이 안된다.
  • 이를 제대로 실행될 수 있는 방법은 Relocation register가 담당한다
  • os가 hwp를 실행할 적에는 Relocation register에 1000이라는 값을 넣는다. 그래서 cpu가 hwp를 실행하려면 0번지에 있다고 생각하니
  • cpu는 0번지를 내어도 limit이 1000이 되어있어 1000번지에 있는 hwp도 실행이 가능하게 된다. (사실은 cpu가 속은것이다.)
  • cpu는 0에 있는줄 알지만, 실제로는 1000에 있는것이다.
• 주소구분
  • 논리주소(logical address, cpu가 내는 주소) vs 물리주소(physical address, 실제로 mmu를 통과해서 메인메모리오 오는 주소)
  • cpu는 항상 모든 주소가 0번지에서 돌고있다고 생각하며 Relocation register를 통해 프로그램들이 메인메모리의 어느 위치든 올리기가 가능해진다.

개인공부 후 자료를 남기기 위한 목적임으로 내용 상에 오류가 있을 수 있습니다.
경성대학교 양희재 교수님 수업 영상을 듣고 정리하였습니다.

이전에 동기화도구로 세마포에 대해서 공부를 했는데, 이 세마포는 굉장히 옛날에 사용하던 방식이다. 이제 많이 사용되는 것은 Monitors이고 이는 자바에서 사용된다.

모니터 (Monitors)

• 세마포 이후 프로세스 동기화 도구
• 세마포보다 고수준 개념

개념

• 공유자원 + 공유자원 접근함수로 구성됨
• 2개의 queues: 배타동기(Mutual exclusion queue) + 조건동기(Conditional synchronization)
• 공유자원 접근함수에는 최대 1개의 쓰레드만 집입가능: 나머지는 큐에서 진입못하고 기다리고 있어야한다.(Mutual exclusion queue에서 대기)
• 진입 쓰레드가 조건 동기로 블록되면 새 쓰데르 진입가능: wait call> 들어왔던 쓰레드는 Conditions synchronization에 갇히게 된다. 그러면 새 쓰레드가 진입가능하다.
• 새 쓰레드는 조건동기로 블록된 쓰레드를 깨울 수 있음: notify()> 블록된 쓰레드를 깨워준다.
• 깨워진 쓰레드는 현재 쓰레드가 나가면 재진입할 수 있음: 하나의 쓰레드만 있을 수 있으니까, 그 비어진 자리에 깨워진 쓰레드가 들어올 수 있게 된다.

자바 모니터

자바에서는 모든 객체가 모니터가 될 수 있다.

• 배타동기: synchronization 키워드를 사용하여 지정 > 한 쓰레드에만 접근이 가능하다.
• 조건동기: wait(), notify(), notifyAll() 메소드를 사용

class C {
  private int value;
  synchronization void f() { // f를 호출하면 다른 쓰레드는 접근 불가능
    ////////code//////////
  }
  synchronization void g() {
    ////////code//////////
  }
  void h() { // 공통변수를 업데이트하는 함수가 아니라는 의미, 이때 이 쓰레드는 동작이 가능
    ////////code//////////
  }
}

모니터 (Monitors) 사용하는 방법

Mutual exclusion

synchronization {
  ////////critical section//////////
}

세마포처럼 공통변수의 앞과 뒤에 acquire, release 혹은 value = 1와 같은 지정이 특별히 필요없고 단시 synchronization만 써주면 된다.

class BankAccount {
  int balance;
  synchronization void deposit(int eat) {
    int temp = balance + ;
    System.out.println('');
    balance = temp;
  }
  synchronization void withdraw(int eat) {
    int temp = balance + eat;
    System.out.println('');
    balance + temp;
  }
  int getBalance() {
    return balance;
  }
}

Ordering

초기값도 지정해주지않고 P1은 곧바로 S1코드를 실행하고 실행이 끝날때 notify()만 해주고, P2는 처음 시작하자마자 wait()을 실행하고 S2 코드를 실행해주게 된다. (깔-끔)

class BankAccount {
  int balance;
  synchronized void deposit(int eat) {
    int temp = balance + ;
    System.out.println('');
    balance = temp;
    notify();
  }
  synchronized void withdraw(int eat) {
    while (balance =< 0)
      try {
        wait();
      } catch (InterruptedException e) {}
    int temp = balance + eat;
    System.out.println('');
    balance + temp;
  }
  int getBalance() {
    return balance;
  }
}

The Dining Philosopher Problem: Monitor로 구현해보기

class Chopsticks {
  private boolean inUse = false //아무도 젓가락을 사용하지 않겠지
  synchronized void acquire() throws InterruptedException { //젓가락을 잡는것 acquire();
    while (inUse) // 누군가가 젓가락을 집고있으면
      wait(); // 기다리고 철학자는 갇혀있게 됨
    inUse = true;
  }
  synchronized void release() { // 젓가락을 놓는것 release;
    inUse = false;
    notify(); // 누군가 큐에서 기다리고 있다면 깨워줘야지
  }
}

개인공부 후 자료를 남기기 위한 목적임으로 내용 상에 오류가 있을 수 있습니다.
경성대학교 양희재 교수님 수업 영상을 듣고 정리하였습니다.

교착상태: Deadlocks

간혹 동기화를 하다보면 Deadlock에 빠지는 경우가 있다. (프로세스 관리에서 해결해야하는 문제중 하나!)

프로세스는 실행을 위해 여러 자원을 필요로 한다. (CPU, 메모리, 파일, 프린터 등..) 어떤 자원은 갖고 있으나 다른 자원은 갖지 못할때(다른 프로세스가 이미 사용중일때) 나머지는 대기를 해야한다. 그리고 다른 프로세스 역시 다른 자원을 가지려고 대기할 때 교착상태 가능성 > 이를 os가 잘못 나누어주면 교착상태에 빠진다.

• 교착상태 필요조건(Necessary Conditions)
  • Mutual exclusive(상호배타): 하나가 사용하면 나머지는 기다려야한다.
  • Hold and wait(보유 및 대기): 하나 가지고 있으면서 나머지가꺼도 기다린다.
  • No Preemption(비선점): 순서를 강제할 수 없고 순서대로 이루어진다.
  • Circular wait(환형대기): 하나의 원을 만들어놓고 있다.

자원(Resource)

Deadlock이 일어나는 이유는 결국 자원 때문이다. 자원(=하드웨어 자원) 자원을 할당받기 위해서는 os에 요청을 하고 요청이 올바르면 자원을 할당해주는데, 이를 다 사용하면 다시 os에게 반납을 하게 되는데, 이런식으로 자원을 사용하게 된다. 이 똑같은 자원이 여러개 있을 수도 있다.(여러개의 자원 = instance)

• 동일 자원
  • 동일 형식(type)자원이 여러개 있을 수 있다.
  • 예) 동일 CPU 2개, 동일 프린터 3개 등
• 자원의 사용
  • 요청(request) -> 사용(use) -> 반납(release)

- 자원 할당도(Resource Allocation Graph)

• 어떤 자원이 어떤 프로세스에게 할당되었는가?
• 어떤 프로세스가 어떤 자원을 할당받으려고 기다리고 있었는가?
• 자원: 사각형, 프로세스: 원, 할당: 화살표
• 교착상태가 되려면 이 그림이 원을 만들고 있어야 한다.

• 교착상태의 필요조건
  • 자원 할당도 상에 원이 만들어져야 한다(환형조건): 충분조건은 아님!
  • 피하려면: 짝수(오->왼), 홀수(왼->오)

교착상태를 처리하는 방법

교착상태 방지(Deadlock Prevention)

교착상태의 4가지 필요조검 중 한 가지 이상을 불만족시킨다.

• 상호배타(Mutual exclusive): 자원을 공유 가능하게 -> 원천적으로는 실현이 불가능하다.
• 보유 및 대기(Hold & Wait): 자원을 가지고 있으면서 다른 자원을 기다리지 않게 -> 일부는 가능하다.
  • 예) 자원이 없는 상태에서 모든 자원 대기, 일부 자원만 가용하면 보유자원을 모두 놓아주기(혹은 가지고 있다면 두개를 동시에 가지도록!)
  • 단점: 자원 활용률 저하, 기아 (starvation)
• 비선점(NonPreemptive): 자원을 선점가능하게 -> 원천적으로는 실현이 불가능하다. (예; 프린터)
• 환형대기(Circular wait)
  • 예) 자원에 번호부여하여 번호 오름차순으로 자원 요청
  • 단점: 자원 활용률 저하

교착상태 회피(Deadlock Avoidance)

교착상태 자체를 자원 요청에 대해 os에서의 잘못된 승인이 이루어져 발생한 것으로 생각한다.

첫번째 예제 - 안전한 할당(Safe Allocation)

• 12개의 magnetic tape 및 3개의 process

두번째 예제 - 불안전한 할당(Unsafe Allocation)

• 12개의 magnetic tape 및 3개의 process

운영체제는 자원을 할당할 때 불안전 할당이 되지 않도록 해야한다. (불안전할당 -> 교착상태, 대출전문 은행과 유사:Banker’s algorithm)
자원을 할당할때 위험한 불안전할당을 하지 않도록 하는 방법

교착상태 검출 및 복수(Deadlock Detection & Recovery)

위의 두가지 방법은 애초에 교착상태가 일어나지 않게 하는 방법이었다면 이는 교착상태는 일어나도록 허용은 하되, 발생하면 복구하도록 하는 방법이다.

• 교착상태가 일어나는 것을 허용
• 주기적 검사: 검사에 따른 추가 부담(overhead)
• 교착상태 발생 시 복수: 프로세스 일부 강제 종료, 자원 선정하여 일부 프로세스에게 할당

이 방법은 os로 하여금 교착상태가 일어나지 않도록 유의하세요. 라고 알려주는게 아니라 프로세스가 필요한대로 자원을 일단 다 나눠주는데, 나눠주다보면 잘 일어나지 않지만 어쩌다가 교착상태가 발생할 수 있다. 이렇게 교착상태가 나타나면 시스템은 동작을 멈추게 되고 이때 이를 해결해줘야 한다.

os의 프로세스 관리부서에서 프로그램이 돌면서 계속적으로 컴퓨터 내부를 교착상태가 일어났는지를 주기적으로 확인한다. 그런데 주기적 검사에서 주기적이라는 단어가 상당히 모호한데, 자주하면 할수록 교착상태를 빨리 알아챌 수 있기 때문에 좋지만 우리가 사용할 수 있는 자원은 한정적이기 때문에 오버헤드의 문제점이 존재한다. 그리고 더 나아가 이렇게 검사를 통해 교착상태를 발견하게 되면 이를 복구해줘야 하는데, 이를 복구해주기 위해서는 주기적으로 현재 상태를 기억을 해야한다. (그러면 또 메모리가 들게 된다) -> 이렇듯 비용이 많이 발생하게 된다.

교착상태가 발생하면 한 프로세스를 강제로 종료를 시키던가, 그게 불가능하다면 자원을 강제로 뺏어서 다른 프로세스에게 할당을 해주면 된다.

이 방법은 말그대로 교착상태 자체가 잘 일어나는 것이 아니기 때문에 자원을 그때그때 그냥 할당을 해주는것을 허용해주는 것인데, 사실 현실적으로 이 방법을 사용하기에는 추가적으로 드는 비용적인 부분들이 많이 들게된다.

교착상태 무시 (Don’t Care)

방법이라고 하기도 그렇지만 이런 교착상태 자체를 무시하는 것이다. 실제로 교착상태가 자주 일어나기도 힘들고(4가지의 필수조건을 충족시키기가 힘들다) pc는 일반적으로 우리가 혼자 쓰고 있기때문에 아예 무시하는 방법을 적용하기도 한다.