네, 반갑습니다. 오늘 이 영상을 끝까지 보신 후에 데드락 개념을 이해하게 되구요, OS에서 데드락을 해결하는 방법과

프로그래밍에서 해결하는 방법을 알게 됩니다. 자, 그럼 오늘도 꼭 오심 잣 애들아, 데드락이 뭔지 한번 살펴보죠.

요게 데드락입니다. 지금 보시면 이 숫자 1, 2, 3, 4가 각각 리소스를 의미해요. 그래서 지금 여기는

4개의 리소스가 있는 거죠. 그리고 지금 보시는 2차 그림이 프로세스가 한번 생각해 보시면 이 차들이 침 답 다 직진을 해서

지나가려고 1 단말 쇼 다 치킨을 해서 지나가려고 하면 반드시 4개의 리소스를 확보를 해야

됩니다. 그런데 마음 급한 이 차들이 서로 빨리 지나가려고 하다 보니까 이 4개의 차량 모두 리소스 하나씩

3점 하는 데는 성공했지만 그 이후에 리소스들은 다른 차량들이 다 가지고 있어 버리는 바람에 지금 오른쪽에

보이는 이 그림처럼 교착 상태에 빠져 버렸죠 그래서 이 차량들은 이제 오도가도 못하고 깨어서 기다릴 수밖에 없는

거예요 이게 상당히 위험한데 왜냐하면 데드락에 빠지면 이후에는 아무것도 진행이 되지 않기 때문이죠 자 그래서

데드락은 2개 이상의 프로세스가 서로가 가진 리소스를 기다리는 상태를 의미합니다 근데 이 데드락을 만들기 위해서는

네 가지 조건이 필요 이 네 가지 조건을 모두 만족하면 데드락이 일어난다고 하는데요 그 조건을 하나씩

살펴보겠습니다 먼저 뮤추얼 익스클루전이에요 이 말은 무슨 말이냐면 2개

소스를 공유해서 사용할 수 없다는 말이에요 그러니까 이 리스트를 사용하려면 한번에 하나씩 하나의 프로세스만 리소스를 사용할 수 있다

라고 생각을 하시면 될 것 같습니다 아 그리고 여기서 우리가 리소스라고 할 때 이 리소스는 우리가 앞에 영상에서 배웠던 어떤 크리티컬 섹션

혹은 이런 것일 수도 있고 우리가 컴퓨터를 구성하는 CPU 메모리 SSD 모니터 프린터 이런 모든 것들도 리소스라고 볼 수 있습니다

자 그래서 다시 돌아와서 이 데드락을 만드는 4가지 조건 중에 첫 번째는 리소스를 공유해서 사용할 수 없다는 거구요

그래서 이 그림에서 보시면 지금 이 리소스들이 1234가 있는데 얘네들을 차량이 공유해서 쓰게 된다 이게 말이

안 되죠 공유해서 쓴다는 말은 곧 두 대가 동시에 사용한다는 의미잖아요 그래서 교통사고는 한 번에 한 대만 가능하기 때문에 이런

루스는 공유할 수 없습니다. 그래서 리소스를 공유할 수 없다는 것이 첫 번째 조건이구요. 두 번째 조건은 폼

된 웨이트입니다. 무슨 말이냐면 프로세스가 이미 하나 이상의 리소스를 취득한 상태에서 다른 프로세스가 사용하고 있는 리소스를 추가로

기다리는 이 조건이 또 있어요. 그림으로 살펴보시면 지금이 오른쪽이 지금 데드락 상태인데 지금 이

상황을 유심히 보시면 모든 차량이 일단 하늘의 소스를 다 확보를 한 상태입니다. 예를 들어서 지금 이

차량을 보시면 이 차량이 이번 리소스를 확보를 한 거죠. 그 상태에서 3번이 소스를 기다리고 있는데 3번이

소스가 이미 다른 차량에 의해서 사용이 되고 있는 상태인 거에요. 이런 상태를 홀드 웨이트라고 하고 이 조건이 데드락을 발생시키기 위한 두

번째 조건이 됩니다 자 그럼 세 번째 조건은 머 프레임 션 이라고 해서 소스 바 나는 오직 크리스트 를 취득한

프로세스와 할 수 있다는 거예요 즉 이미 어떤 리스트를 주고 있다면 다른 프로세스가 이 것을 빼앗아갈 수

없다라는 얘기입니다 이에서 더 보면 이미 이번 리소스를 이 차량이 가지고 있잖아요 이미 이렇게 가지고 있는 상태에서는

아래 보이는 이 차량이 이 이번 소스를 빼앗아 갈 수 없다 란 의미인가요 이번 이 소스는 반드시 이 차량 틈이 차량이 스스로

자발적으로 반환 해야만 다른 차량이 이 소스를 사용 가능하다 이 조건이 바로 세 번째 조건이 되겠습니다 그러면 네 번째

조건은 썰 플러 웨이트 라고 해서 프로세스들이 순한 형태로 서로 열이 소스를 기다린다는 것을 의미에요

아까 그림에서도 보셨던 것처럼 지금 이 차량은 이 차량이 가을이 소스를 기다리고 있고 마찬가지로 이 차량은

그 아래 차량을 가지고 있는 소스를 기다리고 있고 또 이 차량은 바로 그 오른쪽에 있는 촬영일 소스를 기다리고

있고 마찬가지로 또 이 차량은 그 위에 있는 촬영에 리소스를 기다리고 있어서 이렇게 순환하는 형태로 서로가

서로의 프로세스를 기다리고 있는 상태 이런 조건이 바로 이 네 번째 조건입니다 그래서 이 네 가지 조건이 모두 만족되면 데드락이 발생한다고 합니다

자 그러면 이제는 운영 체제에서 이 데드락을 어떻게 해결하는지 그 방법들을 살펴볼게요 지금 이렇게 총 4가지의 방법이

있습니다 있는데 뭐 어느 하나 속시원하게 해결해 주는 방법은 없어요 하나하나 살펴 보시죠 첫 번째 방법은

되도록 방지입니다 얘는 뭐냐면 시스템 레벨에서 디자인을 하는 건데 아까 그 4가지 조건이 모두 충족되어

데드락이 일어난다고 했으니까 그럼 반대로 생각해서 데드락이 일어나지 않게 하려면 근데 까지 조건

중에 하나라도 만족시키지 않으면 되는 거잖아요 그래서 그 네 가지 조건 중에 하나가 충족되지 않게 시스템을 디자인하는

것을 되도록 방지하고 합니다 그러면 첫 번째 방식은 뭐냐면 d 소스를 공유 가능하게 하는 거에요 근데

이 방법은 사실은 현실적으로 불가능하죠 우리가 앞에서 이미 봤던 것처럼 개발에서도 우리가 이유가 있어서

크리티컬 섹션을 만들고 그리 특별 섹션 진입하기 위해서는 반드시 락을 획득해야 되고 이런 것들을 만들었고

또 프린터 같은 경우에는 2개의 프로세스가 동시에 사용할 수가 없죠. 하나가 출력하고 있으면 그 출력이 끝날 때까지는 기다려야 되니까요.

이런 식으로 리소스의 특성상 **뮤추얼 익스클루전**이 보장돼야 되는 리소스들이 있기 때문에 이 방법은 현실적으로 불가능한 방법입니다.

자 그럼 두 번째로 홀딩을 제외한 7을 발생시키지 않는 형태로 데드락을 방지할 수가 있는데요.

사용할 리소스들을 모두 획득한 뒤에 시작하는 방법이 있고 혹은 이 리소스를 전혀 가지지 않는 상태에서 말이죠.

리소스를 요청하도록 하는 제약 조건을 마련하는 방식이죠. 무슨 말이냐면 예를 들어서 지금 이 차가 즉 7해서 지나가려고 한다면 3번과 이 벌리 리소스를 모두 확보한 상태에서 시작하게 만드는 거죠. 혹은 이 차량이 일단

이번 리소스를 취득을 합니다. 취득에 성공했다면 이 발리 소스를 가지고 이런저런 작업을 해요. 그리고

나서 이제 2, 3번 리소스를 취득하려고 한다면 일단은 이미 쥐고 있었던 이번 리소스를 반납을 해야

됩니다. 이렇게 일단 릴리즈를 시키고 난 뒤에 한 번에 2번과 3번 리소스를 요청해요. 그래서 둘 다 획득할 수 있다면 이런

추가적인 작업을 통해서 프로세스를 진행할 수 있는 거구요. 획득할 수 없다면 지금 이번 리소스 쓰레기

미반납 상태이기 때문에 다른 프로세스가 이번 리소스를 획득할 수 있도록 기회를 주는 거죠. 그래서 이런

식으로 홀딩 웨이트 조건이 발생하지 않게끔 하는 방식이 있습니다. 그런데 이 방법은 어떤 단점이 있냐면

예를 들어 만약에 이 두 개를 모두 확보해야만 출발할 수 있다면 그러면 모두 확보한 상태에서 이번에 소스를 가지고 작업을 하고 있는데 그

작업이 오래 걸리는 작업이라면 그동안 2, 3번째 소스는 놀고 있겠죠. 그래서 이 소스 사용 효율이 좀

떨어지고요. 또 어떤 문제가 발생할 수 있냐면 이번 리소스와 3번째 소스가 인기가 엄청 많으면 좀 더 확보하기가 쉽지

않을 수가 있잖아요. 그러면 이 차량은 출발을 못하는 거죠. 그래서 이런 현상을 계속 기다리게 되는 이런

현상을 스타베이션이라고 해서 기아에 허덕인다 이렇게 얘기를 합니다. 세 번째 해결책은 뭐냐면 추가적인

리소스를 기다려야 한다면 님의 획득할 리소스를 다른 프로세스가 3점 가능하도록 한다는 거죠. 이건

무슨 말이냐면 요기 촬영이 이제 지킬 하려고 해요 그래서 이번에 획득했어요 근데 3번을 획득하려고 보니까 이미

차가 이렇게 3번을 획득한 상태입니다 그러면 이런 상황에서 다른 누군가가 이번에 소스를 요청한다면

지금은 이제 친구가 요청하게 쪼이 친구가 측지 나기 위해서 이 벌리 소스를 요청한다면 이미 이 노란색도

로 표시된 이 차장이 이번에 있었을 확보하고 있었지만 지금 이 노란색으로 표시된 차량은 3번 이 소스를

기다리고 있기 때문에 그러면 이 이번에 소스를 이 아래쪽 차장에게 양보를 하는 거죠 이런 식으로 제가 이미 설명했지만 다른

프로세스에게 양보하도록 그렇게 만드는 거죠 사실 이건 이미 우리가 살펴봤는데 CPU에서 컨텍스트 스위칭

할 때 사실 비슷한 얘기죠 시피해서 어떤 프로세스가 작업을 하다가 타임 슬라이스를 다 쓰게 되면 자기가 한

일이 좀 더 남아 있더라도 그 다음 프로세스에게 양보를 하게 되는 거죠 그리고 또 우리가 압전 영상에서 봤던

모니터도 좀 비슷하죠 모니터도 이 크리티컬 섹션이라는 어떻게 보면 일종의 자원을 자신이 확보를 했는데 그

안에서 동작하다가 어떤 특정 조건이 만족될 때까지 기다려야 한다면 자신이 크리티컬 섹션에 들어오면서 쥐고 있던

자원을 반환을 해서 다른 누군가가 크리티컬 섹션에 들어올 수 있도록 허용을 해 주는 거잖아요 그래서 이 모니터가

약간 2절 약값이 차다고 생각해 볼 수 있을 것 같아요 자 네 번째 데드락 방지 방식은 뭐냐면 모든 자원에 순서 체계를

피해서 오름차순으로 리소스를 요청하는 겁니다. 이게 무슨 말이냐면 요 예에서는 지금 이 차가 거기에

해당하는데 4번이 소스를 확보했다면 이후에는 4번 리소스보다 더 큰 숫자를 가진 리소스만 확보할 수 있도록 한다는

거예요. 그래서 이 경우에는 지금 사건이 소스를 확보한 이후에는 1번 리소스를 획득할 수 없죠. 왜냐하면

일반 있었으니 4번 리소스보다 숫자가 낮은 이유죠. 이런 식으로 리소스의 순서 체계를 만들고 오름차순 형태로

요청하고 로 하면 썰 클럽 에이트가 생기는 것을 방지할 수 있습니다. 그래서 만약에 이 차가 직진을 하고 싶으면 4번에 먼저 뜨고

하면 되는 게 아니라 1번을 먼저 획득한 뒤에 그 다음에 4번을 획득해야 되는 거예요. 그러면 이런 식으로

하면은 순환을 발생하지 않기 때문에 그로 인해서 데드락이 발생하지 않게 되는 겁니다. 요 네 번째 접근 방식이 되도록 방지를

위한 네 가지 접근 중에서는 제일 많이 사용되는 방식이라고 합니다. 자 그럼 이제는 쪽 빨리빨리 설명을 할게요. 데드락 해피가 있습니다. 이건

뭐냐면 아까 패 보셨던 데드락, 반기는 시스템 레벨에서 그렇게 디자인을 해서 아예 데드락 자체가 일어날 조건

하나를 없애버리는 거냐면 얘는 실험 환경에서 추가적인 정보를 활용해서 데드락이 발생할 것 같은 상황 자체를 패 버리는 거예요. 여기서

추가적인 정보는 무엇을 의미하며 실행 환경에서 운영체제가 동작을 하고 있는데 그때 현재 사용 가능한 리소스

들 그리고 이미 누군가에게 할당된 리소스가 그리고 미래에 있어서의 있었어 요청이나 관한 등에 관한 정보를 의미합니다.

그래서 이 데드락 회피를 위한 유명한 알고리즘은 뱅커 알고리즘인데요, 그냥 개념만 설명을 드리면

1. 소스 요청을 허락해 줘 쓸 때 데드락이 발생할 것 같은 가능성이 있으며, 그 리소스를 할당해도 안전할 때

까지 계속 리소스의 할당 요청을 거절한 알고리즘이라고 이해를 하시면 될 것 같아요. 자, 그럼 데드락에 대한 감지와 복구

방식이 또 있습니다. 그래서 데드락을 읽다가 허용하는 겁니다. 실행 환경에서 용을 하고 하지만 데드락이 발생이 됐다면 그

데드락으로부터 복구하는 전략을 취하는 거죠. 자, 데드락 감지하는 알고리즘 자체를 뭐 자세히 얘기할 건

아니구요, 어쨌든 데드락이 감지가 됐을 때의 복구하는 전략이 크게 두 가지인데, 하나는 프로세스를 종료시키는

겁니다 좀 극단적으로 보이긴 하는데요 예를 들면 이렇게 되더라 기 발생했잖아요 그러면 프로세스를 종료시킨다

는 말은 두 가지로 나누어 줄 수 있는데 하나는 이 모든 차량을 전인 차들이 끌고 가는 겁니다 그래서 데드락에 빠진 모든

프로세스들을 종료시켜 버리는 거예요 강제 네 이것도 너무 극단적인 느낌이 드니까 이것보다 좀 더 스무스하게

한 명씩 강제로 종료시키는 방법이 있습니다 현명 종료시키고 되더라 게 해결되는지 보고 해결이 안되면 또 한 명 종료

시키고 또 해결되는지 보고 또 해결이 안되면 또 다른 3명 종료시키는 뭐 이런 식으로 하는 거죠

어쨌든 프로세스를 강제로 종료시키는 커지기 때문에 지금까지 진행된 작업을 잃을 수 있다는 측면에서 리스크가 큰

방식이죠. 그래서 이런 식의 접근은 사실 좀 최고의 카드죠. 근데 뭐 어쩔 수 없이 현업에서도 비슷한 상황에서

이런 접근을 하기도 합니다. 뭐 예를 들어 잎의 이 서버가 데드락일 수도 있고 뭐 아닐 수도 있지만 어쨌든

쓰레드가 제대로 동작을 하지 않고 교착 상태에 빠진 것처럼 보여서 서버가 일을 하지 못하는 상태인데

2페이 요청 계속 들어오게 돼요. 이런 경우에는 원인도 잘 안 보이고 급할 때는 일단 이 파일 서버 인스턴스를

데드락(교착상태)은 프로그램에 치명적이죠 T^T 언제 발생하고 어떻게 해결하는지 살펴봅시다~! 간단한 자바 예제도 있어요~!!

8년차 백엔드 개발자가 배워서 남주려고 만든 채널이에요

알기 쉽게 설명합니다

함께 성장했으면 좋겠어요 :)


#컴공맛집 #백엔드전문채널
