[운영체제]6.병행제어 II(1)

이유정·2023년 7월 8일
0

운영체제

목록 보기
19/49

목표

세마포 연산에서 생길 수 있는 문제인 데드락과 동기화와 관련된 전통적인 세가지 문제에 대해 알아본다.

프로세스 동기화: 공유데이터를 여럿이 동시에 접근할 때, 어떤 데이터를 읽어서 수정하고 다시 저장하는게 원자적으로 수행이 안됨으로 인해서 연산하는 도중에 CPU를 빼앗겨서 다른 친구한테 CPU를 줬을 때 생기는 문제다.
어떤 데이터를 읽어오고 수정하는게 CPU에서 한번에 되고, 그 중간에 CPU를 빼앗기지 않는 방법으로 해결가능하다.
프로그래머 입장에서는 기본적인 추상적인 방법이 제공된다는 전제하에 프로그래밍을 하면 쉬울 것이다.

Semaphore 작업을 좀만 잘못해도 문제가 생긴다. 어떠한 작업을 하는데 있어서 semaphore 변수 s랑 q가 있는데 이 작업은 두개를 다 얻어야지만 할 수 있는 작업이라고 해보자. 예를 들어) a라는 변수를 읽어서 b에 저장한다.

deadlock and starvation

자원을 얻는 순서를 s=> q 이런 획득 순서를 만들어주면 deadlock이 생기지 않을 것이다.

classical problems of synchronization

Bounded-buffer poblem

  • 생산자 소비자 문제: 공유 버퍼를 다룬다.크기가 유한한 공유 버퍼(여러 프로그램이 동시에 접근 가능하다.) 프로세스는 생산자 process(데이터를 만들어서 버퍼에 넣어줘), 소비자 process(공유 버퍼에서 데이터를 빼가는 프로세스)가 있다.

buffer조작: 비어있는 버퍼의 위치를 다음 위치로 가리키는 조작
자원의 개수를 세는 것이 가장 적당한건 semaphore임.

1.버퍼를 조작하는 변수, 비어있는 버퍼의 위치가 어딨냐 포인터에 동시 접근하면 문제가 되기 때문에 공유데이터에는 lock을 건다.
2.semaphore 변수는 lock을 걸기위한, 자원 개수를 세기 위한 counting 방법이 있다.

위,
생산자-소비자 문제를 코드로 보여줄게~

생산자 프로세스들, 소비자 프로스들이 공유 버퍼에 동시 접근할 때 문제가 생기기 때문에 버퍼에 락을 거는 semaphore 사용했고, 생산자 입장에서의 자원인 빈 버퍼, 소비자 입장에서 자원인 버퍼를 counting하기 위한 semaphore도 사용했다.

readers-writers problem

읽기 쓰는 문제. 공유 데이터가 있고. 공유 데이터에 접근하는 프로세스는 2개가 있다. 읽는 프로세스와 쓰는 프로세스! 읽고 쓰는 문제를 제한하는 db쪽에서 많이 하는 일이다. 여기선 공유데이터를 db라고 해놧음. db에 대한 동시접근을 막아보자~
읽는건 동시에 읽어도 괜찮아. db에 접근하기 전에 혼자 배타적으로 접근하면 비효율적이다. reader들에 대해서는 동시 접근 가능하게 하고, writer는 배타적으로 접근할 수 있도록 한다!!!

db에 wirter가 접근했을 땐, 다른 read와 writer 누구도 접근할 수 없도록 한다.
db에 small db로 lock을 걸어서 배타적으로 접근할 수 있게 한다. 현재 읽고 있는 프로세스가 몇개가 있는지 readcount가 양수면, 다른 reader가 접근하면 lock이 걸려있어도 같이 읽을 수 있게 한다. readcount가 0이면 다른 reader가 접근하지 않는다는 뜻. 어떤 reader가 오면, lock을 걸고 read를 시작해야 한다. readcount도 공유 데이터다. 이 readcount에 대한 동시접근을 막기 위한 mutex를 사용한다.

위 문제를 ~
코드로 보여줄게 ~

starvation이 발생할 수 있음 : 100개의 reader가 도착했어. 이게 다 읽어야만 writer가 들어갈 수 있음. 99개 빠져나가고 reader가 다시 1000개 도착했어. writer은 또 기다려~~~ 이론적으로 영원히 기다려야 될수도 잇음.
=> 이걸 해결하는 코드를 보여주진 않는다. 실질적으로 starvation이 발생하기는 어려워. 신호등이 왜있겠어? 신호등 없을 때 차가 계속 와. 차 안올 때까지 기다리는데 틈이 안와. => 일정시간 내 동시접근 가능하게 하고 신호등으로 끊어버리고 기다리고 있는 writer한테 기회를 주면 starvation 문제는 해결된다.

dining-philosophers ploblem

식사하는 철학자?
원탁이 있다. 다섯명의 철학자가 앉아서 뭔가를 한다. 생각을 한다!! 또는, 밥을 먹는다! 반복한다 이 두가지 일을 ~ 배고파지는 주기가 각 사람마다 달라. 동기화 되어있지 않고 충돌이 일어날 수 있다. 젓가락이 하필 공유 데이터야 왼쪽 젓가락이랑 오른쪽 젓가락을 모두 얻어야 먹을 수 있음. 동시접근은 안되고 배타적으로 젓가락에 접근해야 한다. 또 하나의 문제는 철학자가 굶어죽으면 안된다~
다들 왼쪽 젓가락 들고, 내놓지 않으면 deadlock 문제가 생긴다 !!


=> 젓가락 두개 다 얻을 수 있을 때 집을 수 있도록 하는걸 더 알아보자 !!!

semaphore의 관점에서 보면 왜 이렇게 코딩했을까 싶은 문제는 있지만 잘 동작하는지만 살펴보자 !

profile
강의 기록 블로그

0개의 댓글