교착 상태 발생

상호 배제는 교착 상태가 발생하기 위한 네 가지 필요조건 중 첫 번째 조건이다. 이 조건은 한 번에 하나의 프로세스만이 특정 자원을 사용할 수 있어야 함을 의미한다. 즉, 해당 자원은 공유될 수 없고, 이미 사용 중인 자원은 다른 프로세스가 접근하거나 사용하는 것이 허용되지 않는다.

상호 배제 조건이 필요한 자원의 대표적인 예는 프린터, 테이프 드라이브, 또는 공유 데이터베이스의 특정 레코드와 같은 비공유 자원이다. 예를 들어, 프린터는 한 순간에 하나의 인쇄 작업만을 처리할 수 있으므로, 한 프로세스가 프린터를 점유하고 있으면 다른 프로세스는 그 작업이 끝날 때까지 기다려야 한다.

만약 모든 자원이 공유 가능하다면, 교착 상태는 발생하지 않는다. 여러 프로세스가 동시에 같은 자원을 사용할 수 있기 때문에, 한 프로세스가 자원을 점유해 다른 프로세스가 무한정 기다리는 상황이 생기지 않기 때문이다. 따라서 상호 배제 조건은 교착 상태를 가능하게 하는 근본적인 토대 중 하나로 작용한다.

점유와 대기는 교착 상태가 발생하기 위한 네 가지 필요조건 중 하나이다. 이 조건은 하나 이상의 프로세스가 현재 일부 자원을 보유(점유)한 상태에서, 다른 프로세스가 보유하고 있는 추가 자원을 얻기 위해 대기해야 하는 상황을 의미한다.

구체적으로, 프로세스 A가 프린터와 같은 자원 X를 할당받아 사용 중인 상태에서, 스캐너인 자원 Y도 필요하게 되었다고 가정하자. 만약 자원 Y가 이미 프로세스 B에 의해 점유되어 있다면, 프로세스 A는 자원 Y가 해제되기를 기다리면서 대기 상태에 들어간다. 이때 프로세스 A는 자신이 이미 보유한 자원 X를 해제하지 않은 채로 대기한다. 이러한 "자원을 잡은 채로 다른 자원을 기다리는" 상황이 점유와 대기의 전형적인 예이다.

이 조건이 없으면 교착 상태는 발생하지 않는다. 예를 들어, 프로세스가 필요한 모든 자원을 사전에 한꺼번에 요청하고 할당받아야만 실행을 시작하도록 강제하거나, 프로세스가 새로운 자원을 요청하기 전에 현재 보유 중인 모든 자원을 먼저 반납하도록 하는 정책을 적용하면 점유와 대기 조건을 제거할 수 있다. 그러나 이러한 방법은 자원 활용도를 저하시키거나 프로세스의 실행을 지연시킬 수 있는 단점이 있다[2].

비선점은 교착 상태가 발생하기 위한 네 가지 필요조건 중 하나이다. 이 조건은 이미 할당된 자원을 다른 프로세스가 강제로 빼앗을 수 없음을 의미한다. 즉, 자원을 점유하고 있는 프로세스가 자발적으로 그 자원을 반환하기 전까지는, 다른 프로세스나 운영체제가 그 자원을 강제로 회수하여 다른 프로세스에 할당할 수 없다.

대부분의 상호 배제가 필요한 자원은 비선점 자원의 특성을 가진다. 예를 들어, 프린터나 테이프 드라이브와 같은 물리적 장치, 또는 공유 메모리의 특정 임계 구역에 대한 접근 권한은 일반적으로 비선점적이다. 한 프로세스가 프린터를 사용하여 문서를 출력하는 중이라면, 그 출력 작업이 완료되기 전에는 운영체제가 프린터 사용권을 강제로 중단시켜 다른 프로세스에 넘겨줄 수 없다. 만약 자원이 선점 가능했다면, 교착 상태에 빠진 프로세스로부터 자원을 강제로 회수하여 다른 대기 중인 프로세스에 할당함으로써 순환 대기 고리를 끊고 교착 상태를 해결할 수 있었을 것이다.

비선점 조건을 제거하여 교착 상태를 예방하는 것은 시스템 설계에 제약을 가져온다. 모든 자원을 선점 가능하게 만드는 것은 현실적으로 불가능하거나 매우 비효율적이다. 예를 들어, 데이터베이스 트랜잭션이 특정 레코드를 갱신하는 도중에 그 자원을 선점당하면 데이터의 일관성이 깨질 수 있다. 따라서, 이 조건을 완화하기 위해서는 자원의 상태를 안전하게 저장하고 복원할 수 있는 메커니즘(예: 체크포인트와 롤백)이 필요하며, 이는 주로 메모리나 중앙 처리 장치와 같은 특정 유형의 자원에 한정되어 적용된다.

순환 대기는 교착 상태가 발생하기 위한 네 가지 필요조건 중 하나이다. 이 조건은 두 개 이상의 프로세스나 스레드가 서로 다른 자원을 점유한 채, 상대방이 점유한 자원을 기다리는 순환 고리가 형성되는 상황을 의미한다.

예를 들어, 프로세스 P1이 자원 R1을 점유하고 자원 R2를 기다리는 동안, 프로세스 P2는 자원 R2를 점유하고 자원 R1을 기다린다면 두 프로세스는 서로 상대방이 자원을 해제하기를 무한정 기다리게 된다. 이러한 순환 구조는 두 개 이상의 프로세스로 확장되어 더 복잡한 고리를 형성할 수도 있다. 이 조건은 다른 세 조건(상호 배제, 점유와 대기, 비선점)이 모두 충족된 상태에서 발생하면 교착 상태를 필연적으로 초래한다.

순환 대기 조건을 제거하는 일반적인 방법은 모든 자원에 전역적인 순서를 부여하고, 각 프로세스가 항상 낮은 번호의 자원부터 높은 번호의 자원 순서로만 자원을 요청하도록 강제하는 것이다. 이 방식을 자원 계층화 또는 자원 순서화라고 한다. 이 정책을 따르면 프로세스들이 자원을 기다리는 방향이 한쪽으로만 흐르게 되어 순환 고리가 생기는 것을 근본적으로 방지할 수 있다.

교착 상태의 주요 원인 중 하나는 프로세스나 스레드가 유한한 시스템 자원을 두고 경쟁하는 상황이다. 시스템의 자원은 프로세서, 메모리, 파일, 프린터, 데이터베이스 레코드 등 다양한 형태를 띠지만, 그 수는 제한되어 있다. 여러 프로세스가 동시에 같은 자원을 필요로 할 때, 그 자원이 한 번에 하나의 프로세스만 사용할 수 있는 상호 배제 조건을 가진다면 경쟁이 발생한다.

예를 들어, 두 개의 프로세스 A와 B가 각각 프린터와 스캐너를 사용하여 작업을 완료해야 한다고 가정해 보자. 프로세스 A가 먼저 프린터를 점유하고, 프로세스 B가 스캐너를 점유했다. 이후 A는 스캐너를, B는 프린터를 추가로 요청하면, 각자 필요한 자원이 상대방에게 점유된 상태이므로 두 프로세스 모두 무한정 대기하게 된다. 이는 단순히 자원이 부족해서가 아니라, 자원을 점유한 상태에서 다른 자원을 요청하는 특정한 순서에 의해 발생한다.

자원 경쟁이 교착 상태로 이어지기 위해서는 일반적으로 네 가지 필요조건이 모두 만족되어야 한다[4]. 자원 경쟁 자체는 병행 시스템에서 흔히 발생하는 현상이지만, 이러한 조건들이 결합되면 시스템이 더 이상 진행되지 못하는 순환 대기에 빠질 수 있다. 따라서 교착 상태를 이해하고 관리하는 것은 이러한 경쟁을 어떻게 조정하느냐에 달려 있다.

교착 상태는 프로세스들이 특정 순서로 자원을 요청하고 획득할 때 발생할 수 있다. 각 프로세스가 실행되는 순서와 자원을 요청하는 시점이 서로 맞물리면, 순환 대기 조건이 성립되어 교착 상태에 빠질 수 있다.

예를 들어, 프로세스 A가 자원 1을 먼저 획득한 후 자원 2를 요청하고, 프로세스 B는 자원 2를 먼저 획득한 후 자원 1을 요청하는 상황을 가정해 보자. 두 프로세스의 실행 순서가 다음과 같다면 교착 상태는 피할 수 있다.

그러나 두 프로세스가 아래와 같은 순서로 동시에 실행되면 교착 상태가 발생한다.

1. 프로세스 A가 자원 1을 획득한다.

2. 프로세스 B가 자원 2를 획득한다.

3. 프로세스 A는 자원 2를 요청하지만, 프로세스 B가 점유 중이므로 대기한다.

4. 프로세스 B는 자원 1을 요청하지만, 프로세스 A가 점유 중이므로 대기한다.

따라서, 운영체제나 응용 프로그램 설계 시 프로세스들의 자원 요청 순서를 일관되게 정의하는 것이 중요하다. 모든 프로세스가 동일한 순서(예: 항상 자원 1을 먼저 요청한 후 자원 2를 요청)로 자원을 요청하도록 강제하면, 순환 대기가 형성되지 않아 교착 상태를 예방할 수 있다. 이는 교착 상태 예방 기법 중 하나이다.

시스템의 물리적 또는 논리적 자원이 제한되어 있을 때, 교착 상태가 발생할 가능성이 높아진다. 운영체제는 프로세스들에게 CPU, 메모리, 입출력 장치와 같은 자원을 할당하여 실행을 지원한다. 그러나 이러한 자원의 총량이 고정되어 있고, 여러 프로세스가 동시에 제한된 자원을 요구하면, 모든 요청을 즉시 만족시킬 수 없는 상황이 발생한다. 이는 자원에 대한 경쟁을 심화시키고, 결국 순환 대기 조건을 형성하는 원인이 된다.

예를 들어, 시스템에 프린터가 단 한 대만 설치되어 있다고 가정해 보자. 두 개의 프로세스가 각각 파일 A와 B를 출력하기 위해 이 프린터를 필요로 한다면, 한 프로세스가 프린터를 점유하는 동안 다른 프로세스는 대기해야 한다. 만약 각 프로세스가 추가로 다른 자원(예: 특정 데이터베이스 레코드에 대한 락)을 보유한 채 상대방이 점유한 프린터를 무한정 기다린다면, 이는 전형적인 교착 상태에 빠지게 된다. 자원의 수가 적을수록 이러한 충돌 가능성은 기하급수적으로 증가한다.

자원의 한계는 단순히 개수뿐만 아니라 풀(pool)의 크기에서도 기인한다. 시스템은 종종 성능이나 안정성을 위해 특정 자원의 최대 사용량을 제한한다. 예를 들어, 동시에 생성될 수 있는 최대 프로세스 수나 열 수 있는 최대 파일 수가 정해져 있다. 여러 프로세스가 이 제한에 도달하여 서로가 해제할 자원을 기다리는 상황이 연쇄적으로 발생하면, 시스템 전체가 마비될 수 있다. 따라서 시스템 설계 시 예상되는 작업 부하를 고려하여 자원 풀을 적절히 확보하거나, 자원 할당 그래프 등을 이용한 사전 모니터링이 필요하다.

자원 할당 그래프는 시스템 내 프로세스와 자원 간의 관계를 시각적으로 표현하는 방향 그래프이다. 이 그래프는 교착 상태를 탐지하는 데 사용되는 주요 도구 중 하나이다.

그래프는 정점과 간선으로 구성된다. 정점은 두 가지 유형으로 나뉜다. 프로세스 정점(P)과 자원 정점(R)이다. 자원 정점 내부에는 해당 자원의 이용 가능한 인스턴스 수를 나타내는 점이 표시된다. 간선은 두 종류가 있다. 프로세스에서 자원을 향하는 요청 간선과 자원에서 프로세스를 향하는 할당 간선이다. 요청 간선은 프로세스가 해당 자원을 요청했지만 아직 획득하지 못한 상태를, 할당 간선은 자원 인스턴스가 특정 프로세스에 이미 할당된 상태를 나타낸다.

교착 상태의 존재 여부는 이 그래프에서 사이클을 찾아냄으로써 판단할 수 있다. 만약 그래프에 사이클이 존재하지 않으면, 시스템은 교착 상태에 있지 않다. 반면, 그래프에 사이클이 존재하면, 시스템이 교착 상태일 가능성이 있다. 특히, 각 자원 유형이 정확히 하나의 인스턴스만을 갖는 경우, 그래프 내의 사이클은 교착 상태가 발생했음을 의미하는 필요충분조건이 된다. 그러나 자원 유형이 여러 개의 인스턴스를 가질 수 있는 경우, 사이클의 존재는 교착 상태의 필요조건이지만 충분조건은 아니다. 이 경우 더 정밀한 알고리즘이 추가로 필요하다.

대기 그래프는 시스템 내 프로세스 간의 대기 관계를 방향 그래프로 표현한 것이다. 이 그래프는 교착 상태 탐지를 위한 주요 도구 중 하나로 활용된다.

대기 그래프의 노드는 프로세스를 나타내며, 방향성 간선은 대기 관계를 표현한다. 예를 들어, 프로세스 P1이 프로세스 P2가 보유한 자원을 기다리고 있다면, P1에서 P2로 향하는 간선이 그려진다. 이는 P1 → P2의 관계를 의미한다. 시스템의 자원 할당 상태를 나타내는 자원 할당 그래프와 달리, 대기 그래프는 프로세스 간의 직접적인 대기 종속성에만 초점을 맞춘다.

교착 상태는 대기 그래프에서 사이클이 존재할 때 발생한다고 판단할 수 있다. 그래프에 사이클이 존재한다는 것은 프로세스들이 순환적으로 서로를 기다리고 있는 상태, 즉 교착 상태에 빠져 있음을 의미한다. 탐지 알고리즘은 주기적으로 이 그래프를 생성하고 사이클 검사를 수행한다. 대기 그래프는 자원 유형을 노드로 표시하지 않기 때문에, 특히 동일 유형의 자원이 여러 개 존재하는 경우 자원 할당 그래프보다 간결한 표현이 가능할 수 있다.

그러나 대기 그래프는 모든 대기 관계가 프로세스 간 직접적인 관계로 환원될 수 있을 때 효과적이다. 일부 복잡한 자원 경쟁 시나리오에서는 자원 할당 그래프를 대기 그래프로 변환하는 과정이 필요하며, 이 변환 과정 자체가 계산 비용을 수반할 수 있다.

교착 상태 예방을 위한 필요조건 제거 기법은 교착 상태가 발생하기 위한 네 가지 필요 조건 중 하나 이상을 시스템이 허용하지 않도록 함으로써, 교착 상태가 절대 발생하지 않도록 보장하는 방법이다.

네 가지 조건 중 하나를 제거하는 대표적인 접근법은 다음과 같다. 첫째, 상호 배제 조건을 제거하는 것은, 모든 자원을 공유 가능하게 만드는 것이다. 그러나 프린터나 테이프 드라이브와 같은 물리적 자원은 본질적으로 상호 배제가 필요하므로, 이 조건을 완전히 제거하는 것은 현실적으로 불가능한 경우가 많다. 둘째, 점유와 대기 조건을 제거하기 위해 프로세스가 실행을 시작하기 전에 필요한 모든 자원을 한꺼번에 요청하고 할당받도록 하는 방법이 있다. 이는 자원의 한계로 인해 자원 활용도가 떨어지고 기아 상태가 발생할 가능성을 높인다는 단점이 있다. 셋째, 비선점 조건을 제거하는 방법으로, 이미 할당된 자원을 강제로 빼앗을 수 있도록 하는 것이다. 그러나 이 방법은 자원의 상태를 저장하고 복원하는 비용이 크며, 프린터와 같은 자원에는 적용하기 어렵다.

마지막으로, 순환 대기 조건을 제거하는 가장 일반적인 방법은 모든 자원에 고유한 번호(전체 순서)를 부여하고, 프로세스가 자원을 요청할 때는 이 번호가 항상 오름차순(또는 내림차순)으로만 요청하도록 강제하는 것이다. 이 정책을 따르면 자원 할당 그래프에 사이클이 형성될 수 없어 순환 대기 조건이 제거된다. 이 기법은 구현이 비교적 간단하고 오버헤드가 적지만, 자원 요청 순서를 애플리케이션 개발자가 미리 알고 있어야 하며, 필요에 따른 유연한 자원 사용을 제한할 수 있다는 한계가 있다.

은행원 알고리즘은 교착 상태를 회피하기 위해 에츠허르 데이크스트라가 제안한 알고리즘이다. 이 알고리즘은 은행이 대출을 승인할 때 고객의 최대 대출 요구량과 현재 가용한 자금을 고려하여 안전한지 판단하는 방식에서 착안하여 이름이 붙었다.

알고리즘은 시스템이 항상 안전 상태에 머물도록 보장한다. 각 프로세스는 자신이 필요로 할 최대 자원의 수를 사전에 선언해야 한다. 시스템은 프로세스가 자원을 요청할 때마다, 그 요청을 허용했을 때 시스템이 여전히 안전 상태를 유지할 수 있는지 시뮬레이션을 통해 검사한다. 검사 결과 안전 상태가 유지될 수 있다고 판단되면 자원을 할당하고, 그렇지 않으면 프로세스는 자원을 할당받기 전까지 대기 상태가 된다.

이 알고리즘을 적용하기 위해서는 몇 가지 전제 조건이 필요하다. 시스템 내의 프로세스 수와 자원의 종류 및 수가 고정되어 있어야 하며, 프로세스는 자신이 필요로 하는 최대 자원량을 미리 명시해야 한다. 또한, 프로세스는 작업을 완료한 후 반드시 할당받은 모든 자원을 시스템에 반환한다는 가정을 한다.

이 알고리즘은 이론적으로는 완벽하지만, 실제 시스템에 적용하기에는 제약이 많다. 프로세스가 필요로 하는 최대 자원 수를 정확히 예측하기 어렵고, 시스템의 자원 수가 동적으로 변하는 환경에서는 사용하기 힘들다. 따라서 주로 학문적 모델에서 설명되며, 실제 시스템에서는 보다 실용적인 다른 교착 상태 처리 방법이 더 많이 사용된다.

안전 상태는 시스템이 교착 상태에 빠지지 않고 모든 프로세스가 필요한 자원을 할당받아 정상적으로 종료될 수 있는 가능성이 있는 상태를 말한다. 반대로, 불안전 상태는 현재의 자원 할당 상태와 프로세스의 최대 요구량을 고려했을 때, 어떤 순서로 자원을 할당하더라도 교착 상태가 발생할 가능성이 있는 상태를 의미한다. 불안전 상태는 반드시 교착 상태가 발생한다는 것을 보장하지는 않지만, 교착 상태가 발생할 수 있는 위험한 조건을 가지고 있다[6].

시스템이 안전 상태를 유지한다는 것은 은행원 알고리즘과 같은 교착 상태 회피 알고리즘이 적용될 수 있는 전제 조건이 된다. 안전 상태를 판별하기 위해 시스템은 각 프로세스의 현재 할당량, 최대 요구량, 그리고 사용 가능한 자원의 수를 고려하여 '안전 순서열'이 존재하는지 검사한다. 안전 순서열이란, 프로세스들이 그 순서대로 자원을 요청하고 반납할 경우, 각 프로세스가 필요한 최대 자원을 얻고 작업을 완료할 수 있는 프로세스들의 진행 순서를 말한다.

따라서 교착 상태 회피의 핵심은 시스템이 불안전 상태로 진입하는 것을 허용하지 않고, 항상 안전 상태 내에 머물도록 자원 할당을 통제하는 것이다. 만약 프로세스의 자원 요청이 시스템을 안전 상태에서 불안전 상태로 만들 것이라고 판단되면, 해당 요청은 즉시 허용되지 않고 프로세스는 자원을 얻기 위해 대기하게 된다. 이 방식은 자원 활용도를 희생시키는 대신 교착 상태를 사전에 방지한다.

자원 할당 정책은 시스템이 프로세스의 자원 요청을 허용할지 말지를 결정하는 규칙으로, 교착 상태를 회피하는 핵심 메커니즘이다. 이 정책은 은행원 알고리즘과 같은 교착 상태 회피 알고리즘을 구현하는 기반이 된다. 시스템은 프로세스가 자원을 요청할 때마다, 해당 요청을 허용한 후의 시스템 상태가 안전 상태에 머물러 있는지 시뮬레이션을 통해 검사한다. 만약 요청을 수락했을 때 시스템이 불안전 상태로 빠질 가능성이 있다면, 해당 요청은 즉시 거부되고 프로세스는 자원을 할당받지 못한 채 대기하게 된다.

주요 자원 할당 정책으로는 다음과 같은 것들이 있다.

이러한 정책을 적용할 때의 주요 고려사항은 성능과 자원 활용도이다. 지나치게 보수적인 정책은 교착 상태는 방지할 수 있지만, 자원 이용률을 낮추고 프로세스의 대기 시간을 증가시켜 시스템 전체 처리량을 떨어뜨릴 수 있다. 반대로 너무 관대한 정책은 교착 상태 위험을 높인다. 따라서 시스템 설계자는 응용 프로그램의 특성과 자원의 종류, 수를 고려하여 적절한 정책을 선택하거나 조합해야 한다. 예를 들어, 프린터나 테이프 드라이브와 같이 교착 상태 발생 시 복구 비용이 큰 자원에는 보수적인 정책을, 주기억장치와 같이 선점이 비교적 쉬운 자원에는 덜 제한적인 정책을 적용하는 경우가 많다.

교착 상태를 복구하기 위한 프로세스 종료 기법은 하나 이상의 프로세스를 강제로 종료하여 점유된 자원을 시스템에 반환하고, 순환 대기 조건을 깨는 방법이다. 이 기법은 크게 두 가지 방식으로 나뉜다.

첫 번째 방식은 모든 프로세스를 종료하는 것이다. 이는 가장 간단한 방법이지만, 이미 상당량의 작업을 수행한 프로세스들까지 모두 중단시켜야 하므로 시스템 전체의 처리 효율이 크게 떨어질 수 있다. 두 번째 방식은 교착 상태에 연루된 프로세스 중 하나씩 순차적으로 종료해보며 순환 대기가 사라질 때까지 반복하는 것이다. 이 경우 어떤 프로세스를 먼저 종료할지 선택하는 기준이 중요해진다.

프로세스 선택 기준은 일반적으로 시스템의 손실을 최소화하는 방향으로 설정된다. 주요 고려 사항은 다음과 같다.

프로세스가 종료된 후, 특정 시점(예: 교착 상태가 발생하기 직전의 상태)으로 시스템을 되돌리는 롤백 작업이 필요할 수 있다. 이는 데이터베이스 트랜잭션과 같이 원자성이 중요한 작업에서 특히 중요하다. 프로세스 종료는 확실한 복구 방법이지만, 작업 손실과 재시작에 따른 오버헤드라는 비용을 수반한다.

자원 선점은 교착 상태에 빠진 하나 이상의 프로세스로부터 자원을 강제로 빼앗아 다른 프로세스에게 할당함으로써 교착 상태를 해소하는 방법이다. 이 기법은 시스템이 교착 상태를 탐지한 후에 수행되는 복구 조치에 해당한다.

자원을 선점할 프로세스를 선택하는 기준에는 여러 가지가 있다. 일반적으로는 최소 비용의 복구를 목표로, 이미 많은 자원을 점유한 프로세스, 낮은 우선순위를 가진 프로세스, 또는 재시작하기까지 남은 예상 실행 시간이 짧은 프로세스 등을 선점 대상으로 선정한다. 선점된 프로세스는 이후 특정 지점(예: 체크포인트)부터 재시작되거나, 완전히 종료될 수 있다.

자원 선점 과정은 세 단계로 이루어진다.

1. 선점: 선택된 프로세스로부터 하나 이상의 필요한 자원을 강제로 회수한다.

2. 롤백: 선점된 프로세스를 안전한 상태(일반적으로 선점 이전의 특정 체크포인트)로 되돌린다.

3. 재시작: 회수된 자원을 대기 중인 프로세스에 할당한 후, 롤백된 프로세스의 실행을 재개한다.

이 방법은 프로세스를 강제 종료하는 것보다 자원 활용도 측면에서 유리할 수 있지만, 선점과 롤백에 따른 시스템 오버헤드가 발생하며, 모든 프로세스와 자원이 선점에 적합한 것은 아니라는 한계가 있다. 특히 프린터나 테이프 드라이브와 같은 비선점 자원에서의 선점은 구현이 매우 복잡하거나 불가능할 수 있다.

데이터베이스 시스템에서 교착 상태는 주로 여러 트랜잭션이 동일한 데이터 항목에 대해 잠금을 설정하고 서로가 점유한 잠금을 기다릴 때 발생한다. 예를 들어, 트랜잭션 A가 레코드 X에 대한 배타적 잠금을 획득하고 레코드 Y의 잠금을 요청하는 동안, 트랜잭션 B는 이미 레코드 Y에 대한 배타적 잠금을 보유한 상태에서 레코드 X의 잠금을 요청하면 순환 대기 조건이 성립되어 교착 상태에 빠진다.

대부분의 현대 관계형 데이터베이스 관리 시스템은 교착 상태를 탐지하고 처리하기 위한 내장 메커니즘을 갖추고 있다. 일반적으로 시스템은 주기적으로 잠금 대기 그래프를 분석하여 순환 의존성을 탐지한다. 교착 상태가 탐지되면, 시스템은 희생자를 선택하여 해당 트랜잭션을 롤백함으로써 교착 상태를 해결한다. 희생자 선택 기준은 일반적으로 롤백 비용이 가장 낮은 트랜잭션(예: 가장 적은 수의 연산을 수행한 트랜잭션)이다.

교착 상태를 완전히 방지하기보다는 탐지 후 복구하는 전략이 데이터베이스 시스템에서 더 일반적으로 사용된다. 이는 교착 상태 예방 기법이 트랜잭션의 동시성을 과도하게 제한하여 시스템 성능을 저하시킬 수 있기 때문이다. 개발자는 애플리케이션 수준에서 교착 상태 발생 가능성을 줄이기 위해 모든 트랜잭션이 일관된 순서로 데이터 항목에 접근하도록 설계하거나, 잠금 유지 시간을 최소화하는 등의 방법을 사용할 수 있다.

운영체제는 프로세스와 시스템 자원을 관리하는 핵심 소프트웨어로, 교착 상태가 발생할 수 있는 전형적인 환경을 제공한다. 특히 멀티태스킹과 멀티프로그래밍을 지원하는 운영체제에서는 여러 프로세스가 한정된 자원을 동시에 요구하며 경쟁하기 때문에 교착 상태의 네 가지 필요조건[8]이 쉽게 충족된다. 운영체제 커널 내부에서도 교착 상태는 발생할 수 있으며, 이 경우 시스템 전체가 멈출 수 있는 치명적인 상황으로 이어질 수 있다.

운영체제에서 교착 상태는 주로 프린터, 테이프 드라이브, 메모리 블록과 같은 물리적 자원이나, 세마포어, 뮤텍스, 잠금과 같은 소프트웨어적 자원을 할당하는 과정에서 발생한다. 예를 들어, 프로세스 A가 프린터를 점유한 채 스캐너를 기다리고, 프로세스 B는 스캐너를 점유한 채 프린터를 기다리는 고전적인 순환 대기 상황은 운영체제가 자원을 관리하는 과정에서 흔히 나타나는 문제이다.

다양한 운영체제는 교착 상태를 다루기 위해 각기 다른 정책을 채택한다. 유닉스 계열 운영체제와 같은 많은 현대 시스템은 교착 상태를 탐지하거나 회피하기보다는, 발생 가능성을 낮추는 설계와 발생 시 수동으로 복구하는 방식을 선호한다. 반면, 실시간 시스템이나 고신뢰성이 요구되는 시스템에서는 은행원 알고리즘과 같은 회피 알고리즘이나, 필요조건 중 하나를 제거하는 예방 기법이 더 적극적으로 적용될 수 있다.

분산 시스템에서의 교착 상태는 네트워크로 연결된 여러 컴퓨터 노드가 서로 다른 자원을 보유하면서 상대방이 가진 자원을 기다릴 때 발생한다. 각 노드는 로컬 자원 관리 정보만을 가지고 있어 전역 상태를 파악하기 어렵기 때문에, 교착 상태 탐지와 해결이 중앙 집중식 시스템보다 복잡해진다. 통신 지연, 메시지 손실, 부분적 장애와 같은 네트워크 특유의 문제들이 교착 상태 관리에 추가적인 변수를 만든다.

분산 교착 상태 탐지 알고리즘은 크게 중앙 집중식, 계층적, 분산식으로 나눌 수 있다. 중앙 집중식 방식은 하나의 코디네이터 노드가 다른 노드들로부터 자원 할당 그래프 정보를 수집하여 분석하지만, 단일 장애점이 될 수 있다는 문제가 있다. 분산식 방식은 모든 노드가 탐지 과정에 참여하여, 확산 기법이나 경로 추적 기법을 사용해 교착 상태 가능성을 협력적으로 판단한다. 이 과정에서 타임스탬프나 고유 식별자를 사용해 탐지 메시지의 중복과 무한 순환을 방지한다.

분산 환경에서의 교착 상태 예방과 회피는 실용적으로 구현하기 어려운 경우가 많다. 대신, 타임아웃 메커니즘을 기반으로 한 교착 상태 복구가 널리 사용된다. 프로세스가 특정 시간 동안 응답이 없으면 해당 작업을 롤백하거나 연결을 재설정하는 방식이다. 분산 트랜잭션을 관리하는 2단계 커밋 프로토콜 같은 경우, 참여자들이 준비 상태에서 영구적으로 대기하는 교착 상태를 방지하기 위해 코디네이터의 장애 시 타임아웃 후 중단하는 절차를 포함한다.

기아 상태는 시스템에서 하나 이상의 프로세스가 필요한 자원을 계속해서 할당받지 못하고 무기한 대기하게 되는 상황을 가리킨다. 교착 상태와 유사하게 프로세스의 정상적인 실행을 방해하지만, 발생 메커니즘은 근본적으로 다르다. 교착 상태가 상호 대기하는 순환 구조로 인해 발생하는 반면, 기아 상태는 특정 프로세스가 자원 할당 정책에서 계속해서 배제되어 발생한다.

기아 상태는 주로 자원 관리나 스케줄링 알고리즘이 공정하지 않을 때 나타난다. 예를 들어, 우선순위 스케줄링에서 높은 우선순위의 프로세스가 지속적으로 유입되면 낮은 우선순위의 프로세스는 실행 기회를 얻지 못할 수 있다. 또한 은행원 알고리즘과 같은 보수적인 자원 할당 정책이 특정 프로세스의 요청을 지연시키는 원인이 되기도 한다.

기아 상태를 완화하거나 방지하기 위한 일반적인 기법은 다음과 같다.

기아 상태는 시스템이 기능적으로 정지된 교착 상태와 달리, 시스템은 정상 동작하지만 일부 프로세스만 영향을 받는다는 점에서 차이가 있다. 그러나 장기간 지속될 경우 시스템의 전체적인 효율성을 저하시키고, 특정 작업이 완료되지 않는 결과를 초래할 수 있다.

라이브락은 하나 이상의 프로세스가 실행 상태에 있지만, 실제로는 진전을 이루지 못하고 동일한 상태를 반복하는 현상을 말한다. 교착 상태와 달리 프로세스들은 CPU를 점유하고 있으며, 실행은 하지만 유용한 작업을 수행하지는 못한다. 이는 주로 프로세스들이 서로의 진행을 방해하는 일련의 상태 변화를 계속 반복할 때 발생한다.

전형적인 예로, 두 개의 프로세스가 각각 하나의 자원을 점유한 채 상대방이 가진 다른 자원을 얻기 위해 대기하는 교착 상태와는 다르다. 라이브락에서는 프로세스들이 자원을 얻으려고 지속적으로 시도하지만, 그 시도의 타이밍이나 조건이 맞지 않아 서로 계속 양보하거나 상태를 변경하기만 할 뿐 실제 자원을 할당받지 못한다. 예를 들어, 복도에서 마주친 두 사람이 서로를 피하려고 같은 방향으로 계속 움직여 길을 비켜주지 못하는 상황에 비유할 수 있다.

라이브락은 교착 상태의 특별한 경우로 간주되기도 하지만, 주요 차이점은 프로세스의 상태에 있다. 교착 상태의 프로세스는 대기 상태에 머무는 반면, 라이브락의 프로세스는 실행 상태를 유지한다는 점이다. 이로 인해 시스템은 멈춘 것처럼 보이지 않을 수 있어 탐지가 더 어려울 수 있다. 해결 방법에는 프로세스들이 행동을 취하는 타이밍을 무작위화하거나, 시도 횟수를 제한하는 메커니즘을 도입하는 것이 포함된다.