21_프로세스 모니터링

21_프로세스 모니터링

 

 

세마포가 프로세스들 간의 동기화를 위해서 편리하고 효과적으로 쓰일 수 있지만 세마포는 잘못하면 발견하기 어려운 타이밍 오류를 야기할 수 있다. 이러한 타이밍 오류들은 특정 실행 순서로 진행되었을 때만 발생하고 이러한 순서가 항상 일어나는 것은 아니기 때문이다.

 

• 세마포와 뮤텍스 : http://sqlmvp.kr/140188335482

 

모든 프로세스들은 mutex라는 세마포 변수를 공유하며 그 초기값은 1이다. 각 프로세스는 임계 구역에 진입하기 전에 wait(mutex)를 실행해야 하며 임계 구역을 나올 때 signal(mutex)를 실행 해야 한다. 이 순서가 제대로 지켜지지 않으면 두 프로세스가 동시에 임계 구역 안에 있을 수 있으며 이러한 문제점들은 하나의 프로세스라도 잘못 행동하면 발생하게 된다.

• 세마포에 대한 wait()와 signal() 연산순서가 바뀐 경우 동시에 임계 구역 안에 위치하게 되어 상호배제 요구 조건을 위배 한다.

 

• 프로세스가 signal(mutex)를 써야할 곳에 wait(mutex)를 사용 하였을 경우 교착 상태가 발생한다.

 

• 프로세스가 wait(mutex)나 signal(mutex) 또는 둘 다를 빠뜨린 경우 상호배제나 교착 상태가 발생한다.

 

 

[모니터(monitor type) 사용]

데이터 유형(type) 또는 추상화된 데이터 유형(abstract data type)은 사적인 자료(private data)를 조작하는 공개 메소드(public method)를 사용하여 보호 한다. 모니터 유형은 모니터 내부에서 상호 배제를 제공하는 프로그래머가 정의한 일련의 연산자를 제공한다.

 

모니터 유형은 변수들의 선언을 포함하고 있는데 이 변수들의 값은 그 유형에 해당하는 한 인스턴스의 상태를 정의한다. 그리고 모니터 유형은 이 변수들을 조작할 수 있는 프로시저 또는 함수들의 본체도 같이 포함하고 있다.

 

모니터 유형의 표현은 다른 프로세스들이 직접 사용할 수 없다. 따라서 모니터 내의 정의된 프로시저만이 프로시저 내에서 지역적으로 정의된 자신의 형식 매개변수를 접근할 수 있다. 모니터 구조물은 모니터 안에 항상 하나의 프로세스만 활성화 되도록 보장해 준다. 그러므로 개발자는 동기화 제약 조건을 명시적으로 코딩 해야 할 필요가 없다.

 

 

 

동기화 기법을 모델링하는 데에는 충분한 능력을 제공하지 않는다. 이를 위해 우리는 부가적인 동기화 기법을 정의해야 할 필요가 있다, 이 동기화 기법들은 condition 이라는 구조물로 제공될 수 있다. 자신의 주문형 동기화 기법을 작성할 필요가 잇는 프로그래머는 하나 이상의 conditicon() 유형의 변수를 정의 할 수 있다.

Condition x, y 유형 변수에 호출 될 수 있는 연산은 wait(), signal() 뿐이 없다. Wait()연산을 호출한 프로세스는 다른 프로세스가 signal()을 호출 할 때까지 일시 중단되어야 하는 것을 의미 한다.

 

x.signal() 연산은 정확히 하나의 일시 중단 프로세스를 재개 한다. 만약 일시 중단된 프로세스가 없으면 signal() 연산은 아무런 효과가 없다. 즉 x의 상태는 마치 연산이 실행되지 않은 것과 같다. Signal() 연산은 항상 세마포의 상태에 영향을 준다. 다음과 같은 예를 살펴 보자.

x.signal() 연산이 프로세스 P의 의해 호출 될 때 조건 x와 연관되어 있는 일시 중단(suspend)된 프로세스 Q가 있다고 가정 할 때 일시 중단된 프로세스 Q가 실행을 재개하도록 허용된다면 신호를 보낸 프로세스 P는 반드시 대기해야 한다. 그렇지 않으면 P와 Q는 모니터 안에서 동시에 활성화 된다. 이 때 두 가지 유형의 가능성이 존재 한다.

• Signal and wait : P는 Q가 모니터를 떠날 때까지 기다리거나 또는 다른 조건을 기다린다.
• Signal and continue : Q는 P가 모니터를 떠날 때까지 기다리거나 또는 다른 조건을 기다린다.

 

이 옵션은 어느 것이든 정당화 하는 근거는 있지만 P가 이미 모니터 안에서 실행 되고 있으므로 signal and continue 옵션을 선택하는 것이 더 합리적인 것처럼 보인다.

 

만약 P스레드를 계속 하도록 허용 한다면 Q가 재개될 때까지 Q가 기다리고 있는 논리적인 조건이 이미 참이 아닐 수도 있다. P스레드가 signal()을 선택하면 즉시 모니터를 떠나 Q가 즉시 재개 된다.

 

 

[세마포를 이용한 모니터 구현 (Implementing a Monitor Using Semaphore)]

각 모니터마다 mutex라는 세마포가 정의되고 그 초기값은 1이다. 프로세스는 모니터로 들어가기전에 wait(mutex)를 실행하고 모니터를 나온 후에 signal(mutex)를 실행 해야 한다.

신호를 수행하는 프로세스는 실행 재개되는 프로세스가 모니터를 떠나든지 아니면 wait() 할 때까지 그 자신이 다시 기다려야 하므로 next라는 세마포가 추가로 필요해 지고(초기값 0) 이곳에서 신호를 수행하는 프로세스가 일시 중단 된다. 정수형 변수 next_count도 next에서 일시 중단되는 프로세스의 개수를 세기 위해 제공 된다. 이와 같이 하면 상호 배제는 보장 된다.

 

[모니터 내에서 프로세스 수행 재개 (Resuming processes Within a Monitor)]

일시 중단된 프로세스는 FCFS순으로 재개 된다. 즉 가장 오래 기다렸던 프로세스가 가장 먼저 깨어나는 것이다. 그러나 많은 경우 이 방법이 충분하지는 않다. 연산이 호출 될 때 값이 계산되며 우선순위 번호라 불린다. 일시 중단되는 프로세스의 이름과 함께 저장 된다. Signal()이 수행 되면 가장 작은 우선순위 번호를 가진 프로세스가 다음 번 수행 재개 된다.

 

프로세스들이 올바른 순서를 지키도록 보장하기 위해서는 RsourceAllocator 모니터와 모니터가 관리하는 자원을 사용하는 모든 프로그램을 검사하여야 한다. 이 시스템에 제대로 동작하는지 알려면 두 가지 조건을 검사하여야 한다.

• 프로세스들이 모니터를 정확한 순서에 맞추어 호출하는지
• 비협조적인 프로세스가 접근제어 프로토콜을 사용하지 않아서 모니터가 정한 상호 배제 규칙 경로를 무시하여 공유 자원을 직접 접근하지 않는다는 것을 보장해야 한다.

 

이 두 가지 조건이 보장되었을 때에만 시간 종속적인 오류가 일어나지 않고 따라서 원하는 스케줄링이 지켜진다는 것을 보장할 수 있다.

 

이런 검사는 적은 규모이며 정적인 시스템에서는 가능할지라도 규모가 큰 프로그램 또는 동적인 시스템에서는 비합리 적이다.

 

 

[참고자료]

Operating System Concept / 홍릉과학출판사