이 글은 원 저자 Jakob Jenkov의 허가로 포스팅된 번역물이다.
원문 URL : http://tutorials.jenkov.com/java-concurrency/slipped-conditions.html
슬립 상태란?
슬립 상태란 한 쓰레드가 특정 상태를 확인하고 이 상태에 대해 어떤 동작을 수행하는 사이에 다른 쓰레드가 상태를 변경하여 처음 쓰레드가 잘못된 동작을 수행하게 되는 현상을 의미한다.
예제를 보자.
public class Lock {
private boolean isLocked = true;
public void lock(){
synchronized(this){
while(isLocked){
try{
this.wait();
} catch(InterruptedException e){
//do nothing, keep waiting
}
}
}
synchronized(this){
isLocked = true;
}
}
public synchronized void unlock(){
isLocked = false;
this.notify();
}
}lock() 메소드가 동기화를 수행하는 방식을 보자. 첫 synchronized 블록은 isLocked 가 false 일 때까지 기다린다. 두 번째 블록은 isLocked 를 true 로 세팅하여 Lock 인스턴스를 다른 쓰레드로부터 잠근다(락을 건다).
isLocked 가 false 이고 두 쓰레드가 동시에 lock() 메소드를 호출하는 경우를 생각해보자. 첫 번째 쓰레드는 첫 synchronized 블록에 진입하자마자 isLocked 가 false 인 것을 확인한다. 그리고 두 번째 쓰레드도 똑같이 synchronized 블록에 진입하고 isLocked 가 false 임을 확인한다. 두 쓰레드 모두 두 번째 synchronized 블록으로 진입하여 isLocked 를 true 로 세팅하고 자신의 동작을
이 상황은 슬립 상태의 예시이다. 두 쓰레드는 상태를 확인하고, synchronized 블록을 벗어나고, 상태를 변경한다(isLocked=true). 이런 동작은 처음 synchronized 로 진입한 쓰레드가 isLocked 에 true 를 세팅하기 전에 다른 쓰레드들이 상태를 확인하는 것을 허용하게 된다. 다시 말해서, '상태' 는 쓰레드의 연이은 확인-변경 동작 사이에 다른 쓰레드들에게로 '탈선'된다.
슬립 상태를 피하기 위해서는 상태의 확인-변경 동작이 원자적으로 이루어져야 한다. 한 쓰레드가 상태 확인-변경 동작을 수행하는 동안 다른 쓰레드들이 상태를 확인할 수 없게끔 하여야 한다는 말이다.
위 예제에 대한 해결책은 간단하다. isLocked=true; 를 처음 synchronized 블록 안, while 루프 바로 다음으로 옮긴다.
public class Lock {
private boolean isLocked = true;
public void lock(){
synchronized(this){
while(isLocked){
try{
this.wait();
} catch(InterruptedException e){
//do nothing, keep waiting
}
}
isLocked = true;
}
}
public synchronized void unlock(){
isLocked = false;
this.notify();
}
}이제 isLocked 상태의 확인-변경 동작은 한 synchronized 블록 안에서 원자적으로 수행된다.
더 현실적인 예제
당신은 Lock 클래스를 위와 같이 구현하지 않을 수 있고, 때문에 슬립 상태는 상당히 이론적인 문제일 뿐이라고 이야기할 수 있다. 첫 번째 예제는 슬립 상태의 개념을 보다 잘 전달하기 위해 다소 단순하게 작성되었다.
더 현실적인 예제는 기아상태와 공정성에서 다룬, 공정한 락 구현 중에 등장한다. 슬립 상태는 중첩 모니터 락아웃에서의 잘못된 구현을 제거하려 할 때 발생하기 쉽다. 아래는 중첩 모니터 락아웃의 예제이다.
// 중첩 모니터 락아웃을 야기하는 공정한 락 구현 public class FairLock { private boolean isLocked = false; private Thread lockingThread = null; private List<QueueObject> waitingThreads = new ArrayList<QueueObject>(); public void lock() throws InterruptedException{ QueueObject queueObject = new QueueObject(); synchronized(this){ waitingThreads.add(queueObject); while(isLocked || waitingThreads.get(0) != queueObject){ synchronized(queueObject){ try{ queueObject.wait(); }catch(InterruptedException e){ waitingThreads.remove(queueObject); throw e; } } } waitingThreads.remove(queueObject); isLocked = true; lockingThread = Thread.currentThread(); } } public synchronized void unlock(){ if(this.lockingThread != Thread.currentThread()){ throw new IllegalMonitorStateException( "Calling thread has not locked this lock"); } isLocked = false; lockingThread = null; if(waitingThreads.size() > 0){ QueueObject queueObject = waitingThread.get(0); synchronized(queueObject){ queueObject.notify(); } } } }
public class QueueObject {}synchronized(this) 블록 안에서 synchronized(queueObject) 와 queueObject.wait() 이 중첩되어 있는 형태를 보자. 여기서 중첩 모니터 락아웃 문제가 발생한다. 이 문제를 피하기 위해서 synchronized(queueObject) 블록은 synchronized(this) 블록 밖으로 옮겨져야 한다.
// 슬립 상태를 야기하는 락 구현 public class FairLock { private boolean isLocked = false; private Thread lockingThread = null; private List<QueueObject> waitingThreads = new ArrayList<QueueObject>(); public void lock() throws InterruptedException{ QueueObject queueObject = new QueueObject(); synchronized(this){ waitingThreads.add(queueObject); } boolean mustWait = true; while(mustWait){ synchronized(this){ mustWait = isLocked } synchronized(queueObject){ if(mustWait){ try{ queueObject.wait(); }catch(InterruptedException e){ waitingThreads.remove(queueObject); throw e; } } } } synchronized(this){ waitingThreads.remove(queueObject); isLocked = true; lockingThread = Thread.currentThread(); } } }
lock() 메소드만 수정되었기 때문에 여기서는 unlock() 메소드는 등장하지 않는다.
이 lock() 메소드에는 세 번의 synchronized 블록이 등장한다.
두 번째 synchronized(this) 블록은 mustWait=isLocked 을 세팅하여 락 상태를 확인한다.
synchronized(queueObject) 블록은 쓰레드가 대기 상태(wait() 호출)로 갈 것인지 아닌지를 체크한다. 다른 쓰레드가 이미 락을 건 상태가 아니라면 이 synchronized(queueObject) 블록을 바로 빠져나간다.
while(mustWait) 으로 인해 세 번째 synchronized(this) 블록은 mustWait 이 false 일 때만 실행된다. 이 블록에서는 isLocked 을 다시 true 로 세팅하고 그외 작업을 수행한다. 그리고 lock() 메소드 수행은 완료된다.
이제 이 FairLock 인스턴스에 락이 걸리지 않은 상황에서 두 쓰레드가 동시에 lock() 메소드를 호출했을 때 어떤 상황이 발생할지 생각해보자. 쓰레드1 은 isLocked 상태를 확인한다. 값은 락이 걸리지 않은 상태이므로 기본값인 false 이다. 다음으로 쓰레드2 도 같은 동작을 수행한다. 그리고 두 쓰레드 모두 대기 상태로 가지 않고 isLocked 를 true 로 세팅한다. 슬립 상태의 전형적인 예이다.
슬립 상태 제거
위 예제에서 슬립 상태를 제거하기 위해서는 마지막 synchronized(this) 블록의 내용이 처음 synchronize(this) 블록 안으로 옮겨져야 한다. 그리고 코드 이동을 위해 자연스럽게 다른 코드들도 조금씩 변경된다.
// 중첩 모니터 락아웃이 없지만 // 신호 실종 문제를 가진 공정한 락 구현 public class FairLock { private boolean isLocked = false; private Thread lockingThread = null; private List<QueueObject> waitingThreads = new ArrayList<QueueObject>(); public void lock() throws InterruptedException{ QueueObject queueObject = new QueueObject(); synchronized(this){ waitingThreads.add(queueObject); } boolean mustWait = true; while(mustWait){ synchronized(this){ mustWait = isLocked || waitingThreads.get(0) != queueObject; if(!mustWait){ waitingThreads.remove(queueObject); isLocked = true; lockingThread = Thread.currentThread(); return; } } synchronized(queueObject){ if(mustWait){ try{ queueObject.wait(); }catch(InterruptedException e){ waitingThreads.remove(queueObject); throw e; } } } } } }
지역변수 mustWait 에 대한 확인-변경 동작은 이제 한 synchronized 블록 안에서 이루어진다. 또한 만일 지역변수 mustWait 를 synchronized(this) 블록 외부에서 검사하더라도 while(mustWait) 안에서 mustWait 은 절대로 synchronized(this) 밖에서 변경되지 않는다. mustWait 을 false 로 판단하는 쓰레드는 내부 조건(isLocked) 를 원자적으로 설정하여, 상태를 확인하는 다른 쓰레드들이 이를 true 로 판단하도록 한다.
synchronized(this) 블록 안의 return 문은 꼭 필요한 것은 아니다. 이것은 작은 최적화의 일환이다. mustWait 이 false 인, 대기 상태로 들어가지 않을 쓰레드가 synchronized(queueObject) 블록으로 진입하여 if(mustWait) 을 실행할 필요는 없다.
관찰력 있는 독자는 위의 공정한 락 구현은 여전히 신호 실종 문제를 가지고 있음을 알 수 있을 것이다. FairLock 인스턴스가 잠겨 있을 때 lock() 메소드가 호출된 상황을 생각해보자. while(mustWait) 안의 synchronized(this) 블록에서 mustWait 은 true 이다. lock() 을 호출하는 쓰레드는 . 그리고 처음 락을 건 쓰레드가 unlock() 을 호출한다. unlock() 메소드 안에서는 queueObject.notify() 가 호출되는데, 대기하는 쓰레드는 아직 queueObject.wait() 을 호출하지 않았다. queueObject.nofity() 는 무효하게 된다. 신호가 실종된 것이다. lock() 메소드를 호출한 쓰레드는 queueObject.wait() 를 호출하여 블록 상태가 된다. unlock() 이 호출되어야 이 블록 상태를 벗어날 수 있지만, unlock() 은 절대 호출되지 않는다.
이 신호 실종 문제는 기아상태와 공정성에서 QueueObject 클래스가 두 메소드와 함께 세마포어로 수정된 이유이다. (doWait(), doNotify()) 이 메소드들은 QueueObject 내부에서 신호를 저장하고, 신호에 반응한다. 이 방법으로 doNotify() 메소드 호출이 doWait() 메소드 호출보다 먼저 발생하는 상황에서도 신호는 실종되지 않는다.
'Java > Concurrency' 카테고리의 다른 글
| 읽기/쓰기 락(Read/Write Locks in Java) (0) | 2017.05.16 |
|---|---|
| 자바의 락(Locks in Java) (0) | 2017.05.09 |
| 중첩 모니터 락아웃(Nested Monitor Lockout) (0) | 2017.04.16 |
| 기아상태와 공정성(Starvation and Fairness) (0) | 2017.04.09 |
| 데드락 방지(Deadlock Prevention) (0) | 2017.04.09 |
