컴퓨터(Computer Science)/운영체제(Operation System)

Readers and Writers Problem, 동기화 [운영체제]

게임이 더 좋아 2020. 5. 21. 17:34
반응형
728x170

 

 

 

여기에서는

읽는 프로세스, Reader

쓰는 프로세스, Writer

2가지가 있다.

 

여기서 공유 데이터는 DB와 readcount가 있다.

 

Write할 때는 db에 다른 프로세스가 접근하면 안되고

Read는 동시에 여럿이 db에 접근이 가능하다.

 

처음에 이해하기로는

Write에는 mutex를 보장해야해서 lock을 걸어야 하고

Read에는 lock이 필요 없다는 말이다.

 

과연 그럴까??

그렇게 이해하면 안되고

db에 lock은

 

read가 일어날 땐 db에 lock을 걸어서 write가 못하게하는 용도고

write가 일어날 땐 db에 lock을 걸어서 read를 못하게하는 용도다.

 

읽기와 쓰기가 같이되면 안되기에 하는 db lock이라는 것이고

 

mutex는readcount에 접근할 때 올바른 readcount 연산을 위해 mutex를 걸어서 연산하는 것이다.또한 readcount가 0이 되었다면 읽기 작업이 끝났으니 그제서야 db lock을 풀어 write를 할 수 있게 한다.

 

 

 

 

 

 

 

 

 


 

이 역시도 세마포로 해결이 가능하다

 

2가지 변수가 있다.

mutex ( lock을 위함)

db (공유 데이터, 자원);

 

readcount : 읽기 작업에 참여중인 프로세스 수

 

 

Writer는

db의 자원을 가져오고

db에 write 작업을 한 후

다시 db 자원을 반환한다.

 

Reader는

lock을 걸고 읽는다. (lock을 걸지 않으면 write 프로세스가 사용할 수 있다)

다만 읽기 작업에서의 lock이라면 다른 프로세스가 read를 한다면 읽을 수 있게 해줘야 한다.

readcount를 1 늘리고

** 처음 읽기 작업을 수행하는 프로세스라면 db에 lock을 걸어준다.(write 작업을 막기 위함)

처음이 아닌 읽기 작업을 수행하는 프로세스면 db에 lock이 이미 걸려있으므로 db에 lock을 걸 필요 없이

그냥 db를 읽기만 하면 된다.

 

하지만 여기서 readcount라는 변수도 공유하는 변수이므로 mutex를 이용해 lock을 걸고 접근하게 한다.

즉, mutex는 readcount라는 공유 변수를 위한 lock이다.

 

그리고 db를 읽고 read작업이 끝나면

빠져나가는데

여기서도 readcount를 쓰기 때문에 mutex로 lock을 걸고 이용한다.

마지막으로 빠져나가는 프로세스라면 후에 다른 write작업이 다시 일어날 수 있게 db에 대한 lock을 풀어서 자원을 반납한다.

 

**다만 readcount가 계속 늘어날 경우 write를 작업을 못하는 경우가 생길 수 있다.

(starvation)

물론 온 순서대로 실행한다면 상관없겠지만

우선순위라던가 특별한 조건이 있다면 "기아" 상황이 발생할 수 있다는 것이다.

 

 

 

728x90
반응형
그리드형