Process Synchronization

 

이 포스트는 서울대학교의 '운영체제의 기초' 강의를 개인 학습용으로 작성한 포스트입니다.

 

 

 

Why Process Synchronization?

왜 프로세스끼리 협력하는가?

시스템이 복잡 -> Modular design (나눠야할게 많음)

Degree of concurrency 증가

Resource sharing

 

* Race Condition (경합 조건) : 여러 Process들이 동기화 절차를 거치지 않고 동시에 자원을 사용하기 위해 경쟁함으로써 그 수행 결과를 예측할 수 없게 되는 상황

 

* Reentrant Code (재진입 가능 코드) : 여러 Process들이 동시에 호출되거나 반복 호출되어도 올바르게 수행되는 코드

 

 

Mutual Exclusion (상호 배제)

오직 하나의 프로세스가 한 시간에 정확한 작업을 할 수 있도록 하는 매커니즘

한 시점에 Critical section에는 하나의 프로세스만 허용됨

하지만, 한 프로세스를 영원히 기다리게해서는 안됨

 

 

Semaphore

Synchronizaiton을 제공해주는 정수형 변수

 

P(S) - wait(S) - lock(S)

V(S) - signal(S) - unlock(S)

 

S가 0이상 일 때 : 남아 있는 자원 개수

S가 0이하 일 때 : Queue에서 대기중인 process 개수

 

Semaphore 단점 : Unstructured programming construct이기 때문에 컴파일러 등을 이용한 디버깅이 어려움

-> Mutex : 동일한 Mutex를 사용할 때 mutex_lock()과 mutex_unlock()을 호출한 process가 일치해야 함 (Valid check)

 

 

구현

 

 

 

* Multiprocessor 환경에서는 Semaphore (Interrupt disable)을 통한 synchronization 어려움

-> Atomic operation을 수행하는 동안 Bus를 장악하여 다른 프로세스 차단

 

* TAS Instruction (Test & Set) : Memory의 Boolean 변수를 읽어서 확인한 후 값을 1로 쓰는 작업 (Atomic)

 

Spin lock (busy waiting)

루프를 돌면서 조건 만족 여부를 확인함

 

while ( TAS(lock_var) != 0)

    // do nothing

// critical section

lock_var = 0;

 

 

Lock Holder Preemption Problem

Spin lock하고 있는데 풀어줄 수 있는 프로세스가 수행못하고 쫓겨난 상황

 

 

Monitor

A programming language construct (ADT) that supports access shared data

Data는 monitor내에서만 접근 가능

 

wait(condition), signal(condition)

 

보호

Shared data structure

Procedure that operate on shared data

Synchronization between concurrent threads

 

 

Hoare style monitor : Wait queue에서 깨어난 프로세스가 바로 Monitor 내부로 진입함

Brinch-Hausen style monitor : Signal을 보낸 프로세스가 수행을 계속함, 깨어난 프로세스는 기다림

 

 

구현

 

* 3개의 queue 존재 : monitor_lock, x_lock, sig_lock (Hoare style monitor에서 signal을 보낸 프로세스가 밖에서 대기하기 위해)