[운영체제 - 질문정리 II] 뮤텍스&세마포어, 데드락

[뮤텍스&세마포어가 무엇인가 - 질문정리]

 

Q. 두 방법의 차이점 중 동기화 대상의 개수말고 또 다른 차이점이 있나요? 

 

   1. 가장 큰 차이점은 동기화 대상의 갯수라고 생각을 하시면 돼요

1. 1. Mutex는 동기화 대상이 only 1개일 때 사용
   2. Semaphore는 동기화 대상이 1개 이상일 때 사용
2. 세마포어는 뮤텍스가 될 수 있지만, 뮤텍스는 세마포어가 될 수 없다.
   1. Mutex는 0, 1로 이루어진 이진 상태를 가지므로 Binary Semaphore! 지만 카운팅 세마포어는 뮤텍스가 될수 있는거죠.
3. Mutex는 소유하고 있는 스레드만이 이 Mutex를 해제할 수 있다.
   1. 반면, Semaphore는 A라는 스레드가 공유 자원을 사용함으로써 세마포어의 값을 감소시켰지만 다른 스레드 B가 공유자원을 사용이 끝나면 세마포어값을 올릴 수 있어요.

 

 

Q. 그럼 스핀락 또한 오버헤드의 한 종류라고 보는 것이 맞을까요?

 

그쵸~ 오버헤드 정의는 다음과 같아요

오버헤드(overhead)는 어떤 처리를 하기 위해 들어가는 간접적인 처리 시간 · 메모리 등을 말합니다. 예를 들어, A라는 처리를 단순하게 실행한다면 10초 걸리는데, 안전성을 고려하고 부가적인 B라는 처리를 추가한 결과 처리시간이 15초 걸렸다면, 오버헤드는 5초가 되는거에요. 스핀락 또한 해당 코드에서 while문 코드를 계속 반복하게 되면 의미없이 계속 CPU가 사용이 됩니다. 그 시간에 CPU를 다른 프로세스나 스레드를 할당시켜서 다른 작업을 할 수 있는게 더 좋은 처리 방식이라고 할 수 있겠죠. 즉, 스핀락 또한 오버헤드의 한 종류라고 볼 수 있습니다.

 

 

 

Q. 세마포어는 P연산과 V연산의 구현 방법에 따라 busy waiting을 해결할 수 있다고 이해하면 되나요? 세마포어는 뮤텍스처럼 다른 알고리즘 예시가 없는지도 궁금합니다!

 

뮤텍스에 데커, 피터슨, 제과점 알고리즘이 있듯이 세마포어에는 Busy-Waiting, Block-Wakeup 알고리즘이 있는거에요~ P연산과 V연산은 세마포어 S 변수를 늘리거나 줄이는 연산일 뿐입니다. 그래서 Busy-Waiting 알고리즘을 사용하면 계속 의미없이 반복문이 돈다고 CPU를 비효율적으로 쓰게됩니다. 그래서 개선된 알고리즘으로 Block-wakeup 방식이 나온겁니다.

---

[데드락이 무엇인가 - 질문정리] 

 

Q. 은행원 알고리즘에서 처음에 모든 사람한테 3달러씩 줬는데 꼭 처음에는 균등분배를 해야하는 건가요? 아니면 그냥 하나의 예시인가요?(B,C에게 각각 4, 6달러 주고 자원 반납하면 나중에 A에게 5달러줘도 될 거 같아서요!)

 

하나의 예시입니다!

예원님께서 말씀하신것처럼 B:4 → C:6 → A:5 이런식으로 진행이 될 수 있겠죠. 또 제가 예로 든 순서 말고도 다른 순서로 줘도 안정상태일 경우도 많을겁니다.

그치만 프로세스가 공유자원을 얼마나 할당받았는지는 모두 다르겠죠~ 예를들면,

현 시점에서 프로세스 A가 자원을 4개를 받을 수도 있고 B가 자원 1개만 받을 수도 있고 C가 10개를 받을 수도 있고 다 다릅니다. 하지만 공유자원의 가용 가능한 수가 별로 남지않았을 때 과연 누구한테 줘야 데드락이 발생하지 않는지는 체크해야겠죠?

즉, 할당할 수 있는 자원이 많다면 그냥 프로세스가 달라고하면 주면되죠. 그리고 이렇게 막 퍼주다가 할당할 수 있는 자원이 줄어들면 불안정 상태가 될 가능성이 커지게 돼요. 그때 은행원 알고즘이 필요하게 되겠죠.

 

 

 

Q. 상호배제 부정 에서 읽기전용파일 같은 공유자원을 사용하는 것도 자원 낭비가 왜 심한지 궁금합니다. 공유하게 되면 오히려 비용이 감소할 수 있는거 아닌가요? 

 

상호 배제 부정은 말 그대로 한 자원에 한 프로세스만 사용하는 것이 아니라 한 자원을 모든 프로세스가 사용할 수 있도록 하는 것입니다. 그래서 해당 공유자원을 수정할 필요 없이 단지 해당 자원을 읽기만 한다면 여러 프로세스가 그 자원을 사용할 수 있겠죠.

그치만 이 상호배제를 무력화하는 것은 사실상 어려워요

예를 들어서, 여러 프로그램을 띄워놓고 각 프로그램에서 프린트를 했어요. 근데 모두 공유자원을 사용할 수 있게 되었으니까 다 뒤죽박죽으로 나오겠죠? 현실적으로 상호 배제를 무력화하는 것은 사실상 어려워요. 상호 배제 부정은 자원 낭비라기 보단 현실적으로 힘든 방법입니다.

 

 

 

Q. 데드락처리 방법의 탐지 및 복구에서 데드락에 빠졌다면 전 상태로 회복한다고 하셨는데 전 상태로 돌아가게되면 다시 또 데드락이 발생할것같은데 탐지 및 복구과정이 필요없는거아닌가요? 그리고 또 전 과정 상태로 돌아가게되면 어떻게 데드락을 해결하나요?

 

데드락이 발생을 했어요~ 그러면 데드락을 풀어야겠죠?

그러면 일단 데드락이 발생시킨 주요 프로세스들을 종료시키면 되겠죠.

방법이 두가지가 있는데, 교착상태를 일으킨 모든 프로세스를 동시에 종료를 하거나, 교착상태를 일으킨 프로세스 중 하나를 골라 순서대로 종료 하는 방법입니다. 이때의 기준은,

• 우선순위 낮은 프로세스 먼저 종료
• 우선순위 같은 경우 작업 시간이 짧은 프로세스 먼저 종료
• 위의 두 조건이같은 경우 자원을 많이 사용하는 프로세스 먼저 종료

그리고 다시 전 상태로 돌아갈땐 이전에 명령어가 실행될 때마다 체크 포인트를 만들어놔요. 그래서 가장 최근의 검사 시점으로 돌아가는 식으로 합니다. 그런데 이 방법은 작업량이 상당해서 시스템 부하준다고 합니다!

 

 

Q. 모든 알고리즘을 짤 때 데드락이 발생하지 않게 예방하면 되지않나요? 예방 외의 다른 해결방법이 있다는것은 데드락을 발생시킬 수 밖에없는 경우가 있다는건데 어떤경우인지 궁금합니다.

 

예방이라는 것은 “상점비순” 이 네가지 조건 중에 하나를 부정한다면 데드락을 피할 수 있다고 말씀드렸어요. 근데 왜 다른 해결방법이 나왔냐면, 데드락은 드문 경우입니다.

근데 그 데드락을 발생시키지 않기 위해서 자원 낭비가 심한 방법이다보니 다른 방법도 나오게 되는거죠. 예방이라는 방법을 사용한다면 데드락은 발생되지 않습니다. 단지, 데드락을 피하기 위해 더 손해보는 선택일 수 있는거죠.