[운영체제(2)]Process Synchronization 1

이유정·2024년 3월 29일
0

운영체제

목록 보기
36/49
post-custom-banner

데이터 접근


컴퓨터 시스템 안에서 데이터가 접근되는 패턴에 대해 이야기해보자.
1) data가 저장되어 있는 위치가 있고,
2) 그 저장된 data를 읽어와서 연산을 보통해서
3) 연산된 결과를 원래 저장 위치 data에다가 저장을 한다.

예시

1) cpu에서 메모리의 data를 읽어들여서 연산을 하고 다시 메모리에 저장을 한다.
2) 연산하는 것을 cpu하고 메모리로 구성된 '컴퓨터'라고 하면, 저장되는 곳은 i/o 장치인 '하드디스크'가 된다. 하드디스크에 있는 것을 컴퓨터 내부로 input, 읽어들인 다음에 연산을 하고, 결과를 다시 output으로 보내서 storage(여기서 하드디스크)에 저장한다.
3) process가 연산의 주체고 , 그 프로세스가 관리하는 메모리 주소 공간이 저장되어있는 위치. process는 보통 실행을 하면서 자기 주소 공간에 잇는 데이터를 읽어다가 연산하고, 그곳에 다시 저장한다.

  • cpu가 하나밖에 없는 시스템에서는 동기화 문제가 발생하지 않을 것 같음
  • 프로세스는 각자의 주소공간에만 접근하기 때문에 여기서도 동기화 문제가 발생하지 않을 것 같음.

Race Condition

  • cpu가 여러개 있는 시스템에서는, 메모리를 공유할 때 동기화 문제가 발생할 수 있다.
  • 프로세스가 메모리를 공유하고 있을 때에도, 동기화 문제가 생길 수 있다.
  • 그런데, 제일 큰 문제는 운영체제 커널과 관련됐을 때 입니다.
    => 프로세스는 일반적인 경우라면 자신 주소 공간만 접근하기 때문에 Race Condition, synchronization 문제가 발생할 일 없음. 근데 프로세스들이 본인이 직접 실행할 수 없는 부분, 즉, 운영체제한테 요청해야 하는 부분은 시스템콜을 한다. 커널의 코드가 그 프로세스 대신에 실행되고, 근데 커널의 코드가 실행된다는 것은 커널의 데이터에 접근한다는 뜻. 만약 이 상황에서 cpu를 뺏겨서 또 다른 process한테 넘어갔는데, 시스템콜을 해서 , 커널 코드가 실행돼서 그 데이터에 접근할 때 race condition 문제가 발생할 수 있음. 혹은 실행중일 때 인터럽트가 들어올 수 있음. 인터럽트 실행도 커널코드임. 지금 하던일은 잠시 잊고, 인터럽트 실행 코드를 한다는 것.운영체제의 커널 코드 데이터는 여러 프로세스들이 동시에 사용할 수 있는 데이터 이기 때문에 문제가 생김/

OS에서 Race condition은 언제 발생하는가?

OS에서의 Race condition (1/3)


작업 중 interrupt가 들어왔을 때, interrupt handler 발생. intterupt handler도 커널 코드다.

결과: 1 증가한것만 반영이 된다.
1 load 했는데,
interrupt handler가 count 가져가서 -1 했어
근데 이미 load 한걸로 +1 을 하니까,
결과적으로 count가 +1만 되어있음.

  • 중요한 변수 값을 건드리는 동안에는, interrupt가 들어와도, 작업이 끝날 때까지 interrupt를 disable 시킨다. => race condition 발생하지 않게 한다.
  • 그런데 무작정 막으면 효율적이진 않으니, 차차 이야기해보자.

OS에서의 Race condition (2/3)


  • 프로세스 A가 usermode에서 시스템콜을 하고, 커널 모드였다. 그 와중에 cpu 할당 시간이 끝나서 프로세스 B한테 cpu가 넘어갔다. 이 프로세스도 user mode에서 시스템콜을 통해 커널이 cpu를 갖고 있었다. 그리고 할당시간이 끝나서 cpu가 다시 A한테 넘어갔다. 그런데 B가 count+1 한걸로 count+1 하지 않고, A프로세스의 이전 문맥의 count의 +1 을해서 결과적으로 count가 +1 만 됐다.

해결책

  • 커널 모드에서 수행중일 때는 cpu를 빼앗기게 하지 않는다.
    => 커널 모드가 끝나고 user mode로 넘어갈 때 cpu를 뺏는다.
    => cpu 할당시간이 일정하진 않지만, time sharing 시스템은 real time이 아니기 때문에 괜찮음.
    => 오히려 race condition 문제를 쉽게 해결

OS에서의 Race condition (3/3)

  • cpu가 여러개 있는 환경
  • 이 수업에서 자주 등장하는 경우는 아님.
  • 이 문제는 앞에 해결책 중 어떤걸로도 해결 안됨
  • 인터럽트 막아도, 다른 cpu가 함.
  • 아직 작업이 끝나지 않았으면 lock을 걸어서 그 데이터에 접근하지 못하게 한다.
  • 작업 끝나면 unlock 한다.
  • 커널 전체에다가 lock을 거는 방법 1은 비효율적임(한번에 하나의 cpu만 커널에 들어가게)

Process Synchronizaion 문제

  • 여럿이서 동시에 접근하다가 시간적으로 맞아 떨어지지 않는 문제
  • 매커니즘 ex) 하나가 data를 수정하는 동안에는 다른 애는 접근 못하게 막는 방법
  • race condition 막기 위해서는 동시에 실행하는 process간의 동기화가 잘돼야 한다.


저 빨간 줄 인 경우에 보통 문제가 안생긴다.
아래 두 경우에 race condtion이 생기는 것임/
1) 두 프로세스간에 shared memory를 쓰고 있다든지.
2) process1 실행 도중 커널 데이터를 건드리는 동안에 process2한테 cpu가 넘어가든지/

The Critical-Section Problem(임계 구역)

critical section: 공유 데이터를 접근하는 코드

p1이 critical section 안에 들어가 있으면,
공유 데이터에 접근하는 코드를 실행중이면,
cpu를 뺏겨서 다른 p2 한테 cpu가 넘어가더라도
p2 는 공유 데이터를 변경하는 critical section에 못들어가게 한다.

profile
강의 기록 블로그
post-custom-banner

0개의 댓글