목표
동기화의 문제에 대해 알아본다.
데이터의 접근
컴퓨터 안에서 연산이 이뤄지면서 데이터에 접근하는게 어떻게 이뤄지는지/ 동기화가 왜 문제인지 말해보자.
컴퓨터에서 연산을 할 때는 데이터를 읽어와서, 연산을 하고, 그 결과를 어딘가에 저장하도록 되어있다.
여기서 문제가 생기는데 왜??
한군데에서 메모리에서 데이터를 읽어가는게 아니고, 여러군데에서 읽어갈 때 문제가 생긴다!
예를 들어
Race Condition
- cpu가 1개든 여러개든 문제가 안 생긴다는 관점
: 어처피 process 자기 주소 공간에 있는 데이터에만 접근할 수 있으니까 Race Condition이 왜 생기냐~
- cpu가 1개든 여러개든 문제가 생긴다는 관점
: 문제는 운영체제가 끼어들 때 생긴다. a라는 프로그램이 실행중이다. cpu를 잡고. a process는 본인이 할 수 없는 일을 운영체제한테 해달라고 시스템 콜을 요청한다. 운영체제안 어떤 데이터의 값(커널의 데이터)을 바꾸고 있었어. 자신의 cpu 할당 시간이 끝나서 cpu가 process a에서 process b한테로 넘어갔다. 어처피 자기 자신의 주소공간의 데이터만 접근했는데, 자기도 운영체제한테 시스템 콜을 한 것이다. 그러면 또다시 운영체제의 코드가 실행이 될것이다. 운영체제가 a할 때 건든 데이터를 b할때도 건드리게 되어버렸다. 동일한 데이터를 건드릴 수 있는 것임.
OS에서 race condition은 언제 발생하는가?
문제의 원흉은 운영체제 때문이라고 할 수 있다!!!!
os에서의 race condition(2/3)
- 시스템콜 먼저 예시 들어볼게
user mode에서 본인의 프로그램을 실행할 때는 본인의 주소공간에 있는 데이터에 접근할테니까 race condition이 문제가 될게 없다. 그런데 시스템콜을 해서 커널의 코드를 실행하게 되면 커널의 데이터를 건드리게 되는데 , 그건 공유 데이터니까 문제가 생긴다.
만약, 커널의 데이터를 건드리는 도 . 중. 에 cpu를 빼앗기게 되면 race condition이 생길 수 있게 된다. 라는 뜻이다.
이미, 읽어드린 레지스터(a는 1을 못 증가시킴) 값에서 1을 증가시키고(b), 분명히 변수를 두번 증가시킨 것 같지만!!! 다시 cpu를 받았을 때 a에서 증가시킨다. 그니까 결론은 a에서만 증가시킨 것만 반영이 되어있다.
os에서의 race condition(1/3)
- 운영체제에서 인터럽트가 발생될 때!!!
이미 커널에선 레지스터에서 값을 불러들였기 때문에 interrupt handler가 감소시킨 count 값은 반영이 안되고, count = 0 에서 +1을 한게된다.
os에서의 race condotion(3/3)
- cpu가 여러개 있는 상황에서
이것도 결국,운영체제의 코드를 수행할 때 문제가 생기는 것이다~~~
해결할 때 cpu a에서 인터럽트를 막았다고 cpu b에서 인터럽트를 못하는게 아니다., (이게 어디쪽 설명인지 기억안남 ㅎㅎ; )
proccess Synchronization 문제
이제 process synchronization에 대해 알아보자~~~
example of a race condition
the critical-section problem
공유데이터를 건드리는 코드를 critical-section이라고 한다.
설령 cpu를 빼앗기더라도, 다른 친구가 critical section은 수행하지 못하게
