12. Process Synchronization 1

데이터의 접근, 경쟁 상태

• 데이터 공유 상황에서 누가 언제 어떤 데이터를 읽고 연산했는지에 따라 원하지 않는 결과가 나올 수 있기 때문에 그에 맞는 처리 필요

• 커널모드에서 1까지 수행하다가 인터럽트가 걸린다면 count가 감소한 작업은 인터럽트 처리 이후, 이전에 불러온 count값을 연산한 값으로 덮어씌워지므로 증가한 결과값만 남게 된다
• 해결: 중요한 변수를 다루는 동안에는 인터럽트가 걸려도 그 작업을 마칠때까지 인터럽트 처리 보류

• real time 시스템의 엄밀한 상황이 아닌 time sharing 시스템이므로 이렇게 쉽게 해결하고 가는 것이 좋다

• 효율: CPU lock/unlock << data lock/unlock

• 각 프로세스별로 독자적인 주소 공간이 있으므로 타이머 인터럽트로 문맥 교환이 일어나는 것은 문제가 되지 않음

• 프로그램적 해결법의 충족 조건
  • mutual exclusion: 어느 프로세스가 critical section 부분을 수행 중이면 다른 모든 프로세스들은 그들의 ciritical section에 들어가면 안된다
  • progress: 아무도 critical section에 있지 않은 상태에서 critical section에 들어가고자 하는 프로세스가 있으면 허용해주어야 한다
  • bounded waiting: 프로세스가 critical section에 들어간다는 요청 이후 그 요청이 허용될 때까지 다른 프로세스들이 critical section에 들어가는 횟수에 한계가 있어야 한다
  • 가정
    • 모든 프로세스의 수행속도는 0보다 크다
    • 프로세스들 간의 상대적인 수행 속도는 가정하지 않는다

• 0의 입장에서, 1이 critical section 수행 중이면 while문을 돌며 대기하다가 1이 turn을 넘겨주면 0이 critical section 코드 수행하고 다 끝나면 turn을 다시 넘겨준다
• 특정 프로세스가 더 빈번히 critical section이 필요하다면 다른 프로세스가 critical section이 더이상 필요없는 시점부터는 다시 turn을 돌려받지 못한다

• 한 프로세스가 깃발을 들고 CPU를 뺏기면 CPU를 건내받은 다른 프로세스가 깃발을 들고 어떤 프로세스가 깃발을 들고 있는 것이 확인되므로 while문에서 대기하게 되는데, 결국 둘다 critical section에 들어가지 못한다

• busy waiting (=spin lock): CPU를 받았지만 while문에서만 계속 대기만하다 할당시간이 끝나는 상황은 비효율적
• 소프트웨어적으로 lock/unlock하는 코드가 복잡해지는 것은 한 인스트럭션 수행 도중에도 CPU를 뺏길 수 있기 때문

• 데이터를 읽고 쓰는 행위를 하나의 인스트럭션에 수행가능하다면 문제 해결 가능 -> Test_and_set()

 

출처: https://core.ewha.ac.kr/publicview/C0101020140401134252676046?vmode=f 

https://core.ewha.ac.kr/publicview/C0101020140404144354492628?vmode=f