멀티쓰레드 사용 시, 데드락에 관하여..
- 데드락의 발생 조건
- 데드락을 해결을 위한 방법들
데드락의 발생 조건
아래 4가지 조건을 동시에 충족하면 데드락이 발생한다.
1. Mutual Exclusion(상호배제, mutex - 자원에 대한 동시접근 불가)
한번에 여러 프로세스(혹은 쓰레드)가 한 자원에 접근하지 못하도록 막음
(만약 동시에 자원 접근이 가능하다면 애초에 다른 프로세스가 다 쓰길 기다릴 필요가 없다)
2. Hold and Wait(점유대기)
자원을 가지고 있는 상태에서 다른 프로세스가 쓰는 다른 자원을 기다리는 상태
3. No Preemption(선점불가)
다른 프로세스가 이미 점유한 자원을 강제로 뺏어오지 못함
우선권이 우선한다는 뜻의 "선점"
4. Circular Wait(환형대기, 순환 형태로 대기함)
내가 일을 하려면 내가 일을 끝내야 수행이 가능한 모순적인 상황 (돌고 돌아서 나에게 돌아옴)
그럼 이 데드락을 해결하려면?
- 예방
- 회피
- 탐지 / 회복
- 무시
데드락의 예방(Prevention)
위 4가지 조건은 동시에 충족돼야 데드락이 발생한다. 그러므로 그 중 하나라도 발생하지 않도록 시스템 차원에서 막아버리면 해결된다.
근데 이 방법은 대부분 자원이 낭비되는 경향이 있다. 발생 가능성을 원천봉쇄하려면 성능이 나빠지거나 또 다른 문제를 발생시킬 수 있다.
데드락의 회피(Avoidance)
교착상태의 원칙적인 발생 가능성(조건)은 그냥 두고, 발생을 막는 알고리즘을 적용해서 해결한다.
은행원 알고리즘(프로세스가 자원을 요구하는 시점에 자원을 할당해도 안전한지를 검사하여 데드락을 막는 방법)
자원할당 그래프 알고리즘 등
데드락의 탐지(Detection)와 회복(Recovery)
교착상태가 발생하는 것을 아예 안막음. 발생하면 그때서야 해결.
데드락 무시
무시해도 좋을 확률로 데드락이 발생한다고 판단되면 그냥 무시
왜냐면 데드락 문제는 해결하려면 성능상 손해를 봐야 하기 때문
안정성과 성능을 고려해서 데드락 문제를 해결할지 말지를 정한다.
'Programming' 카테고리의 다른 글
[Database] 트랜잭션 격리수준에 관하여.. (데이터베이스 Transaction isolation level) (0) | 2021.08.31 |
---|---|
[네트워크] 세션과 토큰에 관하여.. (feat. 쿠키) / Session, Token, Cookie, Network (0) | 2021.08.30 |
Java 의 final keyword 에 관하여.. (0) | 2021.08.26 |
Spring framework, @Transactional(readOnly=true), 스프링 프레임워크 읽기 전용 트랜잭션을 하는 이유는? (0) | 2021.08.03 |
네트워크 망 구성 (AWS) 에 관하여.. 순서 등 (0) | 2021.08.01 |