📌 Process Synchronization 1

모깅·2023년 5월 9일

컴퓨터 시스템안에서 데이터가 접근되는 패턴
-> 저장된 곳이 있을 거고 그 저장된 데이터를 읽어와서 연산을 해서 연산된 결과를 원래 위치에 저장한다.
읽기만 한다면 문제가 되지 않지만 데이터를 읽어와서 연산을 하고 결과를 다시 저장하는 과정은 누가 먼저 저장하는냐에 따라 결과가 달라질 수 있고 그 때 생기는 문제를 synchonization문제라고 한다.

Storage box를 여러 Excution box가 공유한다고 하면 어떤 문제가 생길까?
-> count++결과가 반영되기 전에 count--가 실행되고 count++ 반환후 count--가 반환된다면 count++은 실행되지 않은 것과 같게 된다. (1뺀거만 반영)
하나의 데이터를 동시에 접근하려고 할 때 Race Condition이라고 한다.
process는 일반적으로 자기 주소공간만 접근하기 때문에 Race Condition이 발생하지 않는다
-> 그러나 운영체제에 요청해야 하는 부분에 대해서는 시스템콜을 한다.
-> 커널의 코드가 그 프로세스를 대신해서 실행이 되고
-> 커널의 코드가 실행된다는 의미는 커널의 데이터를 접근한다는 의미이다.
-> 커널의 코드를 실행하는 도중 다른 process에게 CPU가 넘어가게 됐을 때
-> 이 친구 시스템콜을 해서 커널에 데이터를 접근할 수 있다
-> Race Condition 발생
커널의 코드가 실행중일 때 interrupt가 발생할 수 있다.
-> 하던 일을 중지하고 interrupt를 처리한다.
-> interrupt를 처리하는 코드 또한 커널의 코드이기 때문에 Race Condition이 발생한다.
유저 레벨에선 별 일이 없지만 커널에서 문제가 생길 수 있다.

고급언어로 된 1증가시키는 문장이 CPU내부에서는 여러개의 instruction으로 실행된다.
-> 메모리에 있는 count라는 변수 값을 CPU안에 register로 불러들이고 값을 1증가 시킨 후 register의 값을 메모리에 다시 올려둔다.
데이터를 register로 읽어드린 시점에서 interrupt가 들어왔을 때 작업을 멈추고 인터럽트 처리 루틴으로 넘어가게 된다.
-> interrupt handler 또한 커널 코드이기 때문에 count--를 접근 할 수 있다.
문제를 해결하기 위해서는?
-> 중요한 변수를 건들이고 있는 상황에서는 interrupt가 들어와도 interrupt 처리루틴으로 보내지 않는다. (instruction이 끝난 후 처리 할 수 있도록 한다.)

운영체제에게 특정 서비스를 부탁하는 경우가 존재한다.
process마다 CPU 할당시간이 존재하고 그 시간이 끝나면 CPU를 반납해야 한다.
user레벨에 있다가 시간이 끝나면 상관없는데
-> system call을 통해 kernel모드가 수행중이다.
-> 이 때, count의 값을 증가시키는 도중 CPU 할당시간이 종료되면 B에게 CPU가 넘어가고 count에 접근한다.
-> count++은 한번만 적용 될 것이다. (덮어쓰기)
해결책!
-> 커널모드에 있을 때는 CPU를 뺏기지 않게 한다.

critical 문제를 해결하기 위해서 만족해야 하는 3가지 조건
Bounded Waiting : process가 critical section에 들어가기까지 너무 오랜 시간 기다려서는 안된다.(starvation X)

코드는 critical-section이거나 아니거나 즉, 공유 데이터를 접근할 수 있는 코드이거나 아니거나로 나눌 수 있다.
공유 데이터에 접근 할 수 있는 코드를 critical section이라고 한다.
공유 데이터를 그냥 접근하게 하면 동시접근을 통해 문제가 생길 수 있기 때문에 접근 이전에 entry section을 넣어서 lock을 걸어야 한다.
-> critical section이 끝나면 lock을 풀어서 다른 process가 critical section에 접근 할 수 있도록 해야한다.

코드에서 lock을 걸고 푸는 방법을 알아보자.
critical section에 들어왔다 나가기 전에 CPU를 뺏기지 않으면 문제가 발생하지 않을 것이다.
-> 즉, 고급언어에서 instruction이 한번에 실행되는것이 아니라 나눠져서 실행되기 때문에 중간에 CPU를 뺏길 수 있다. (문제점)
while (turn != 0) : 내 차례가 아닌 동안에 계속 while문을 돌겠다.
이 코드는 mutual exclution을 만족시킨다.
-> 그러나 progress는 만족시키지 못한다.
P0가 더 빈번하게 critical section에 들어가고 싶어도 P1이 critical section에 들어가야만 P0가 들어갈 수 있다.
P1이 critical section에 한번만 들어간다면 P0는 빈번하게 들어가고 싶어도 한 번 밖에 들어가지 못한다.
따라서 Algorithm 1은 문제를 제대로 해결하지 못한다.

flag라는 변수를 사용하고 있다. process는 각각 자신의 flag를 가지고 있다.
-> flag는 본인이 critical section에 들어가고자 하는 의지를 표현한 변수
flag를 true로 한 후 CPU를 뺏긴 후 다른 process에서도 flag를 true로 하면 서로 while문에서 빠져나가지 못하는 상황이 연출 될 수 있다.
-> critical section 이후에 falg = false하기 때문이다.
-> progress 문제점이 발생 할 수 있다.(아무도 들어가지 못한다.)

데이터를 읽고 쓰는 것을 하나의 instruction으로 해결 할 수 없기 때문에 일어나는 일이다.
-> 하나의 instruction이라면 문제가 발생하지 않을 것이다.
-> inturrupt도 하나의 instruction을 해결하고 확인한다.
읽고 쓰는 작업이 하나의 H.W instruction으로 실행 될 수 있다면 비교적 간단히 lock을 걸고 푸는 문제를 해결 될 수 있다.
-> Test_and_set(a) : a를 읽어내고 a의 값을 1(True)로 변경하는 것이 하나의 instruction
lock 이 0(False) 이었다면 1로 만들고 while문 통과
1(True) 이었다면 while 문에서 대기후 그대로 1로 유지