동기화 도구들

경쟁상황이 발생할 수 밖에 없는 이유

• 전혀 다른, 이기종의 두 물체가 서로에게 영향을 줄 수도 있고
• 프로세스간 공유메모리 사용은 너무 당연하고
• 멀티프로세서등복잡한게 많이 생겼다.

경쟁 상황의 예시

• 커널 코드에서 잘 발생할 수 있겠지

임계구역 문제에 대한 해결안 3가지

critical section을 어떻게 해결할 것인가?

둘 이상의 프로세스가 공유자원에 절대 접근해서는 안 되는 구역이다.

• 상호 배제 - 한번에 한 친구만 접근
• 진행 - Critical Section에서 실행중인 프로세스가 없다면, 다른 프로세스가 접근할 수 있도록 한다.
• 한정된 대기 - 언젠가는 실행되어야 한다.

그냥 정말 나이브한 처리 방법

선점이면 괜찮겠찌만, 당연히 성능 구데기

다중 처리기에서는 인터럽트 끄는 거 만으로도 해결 안 됨

피터슨의 처리 방법

• 일단, flag는 나에게로 가져온다.

• 만약, flag[i]와 flag[j]가 동시에 true로 변한다면, 아무도 진입할 수 없다.

  따라서 turn을 상대방에게 넘겨줌으로써 해결한다.

• 컴파일러에 의해 동작순서가 바뀌면 먹히지 않을 수 있다.

  turn과 flag의 순서만 뒤바뀌어도 꼬인다.

• 턴이 내 턴이면서, 상대방이 false일 때 진입 가능

동기화를 위한 하드웨어 지원

메모리 장벽

• 강한 순서 : 프로세스의 메모리 변경 결과가 다른 프로세스에 바로 보임
• 약한 순서 : 프로세스의 메모리 변경 결과가 바로 적용되지는 않는다.

• 무조건, barrier 뒷줄부터는 메모리에 저장되고 나서 실행되게끔 한다.

하드웨어 명령어

원자적으로 만든 하드웨어 명령어.

• TAS

무조건, target을 True로 바꾸고 기존 값을 리턴시킨다.

lock의 기존 값은 False이겠지.

한정된 대기 조건은 만족하지 못한다. 즉 어떤 프로세스는 독점을 당해서 계속해서 기다리게 될 수도 있다.

• CAS

• waiting queue를 이용한 CAS

bounded waiting을 만족시키기 위해.

원자적 변수

적절한 스핀락의 시간

문맥교환으로 잠시 나갔다가 들어왔을 때 바로 실행되는게 베스트.

Mutex Lock

semaphore

• 음수 : 기다리고 있는 프로세스의 개수
• 양수 : 남는다.++++
• 0개 : 기다리는 프로세스가 없고, 딱 다 사용함
• 큐에는 포인터를 저장한다.

• 멀티 프로세서에서는, TAS나 CAS 등을 이용한다.

• TAS와 CAS가 두 개의 프로세서에 동시에 들어가게 되면,, 훔훔훔,,

  따라서, 이러한 현상을 막기 위해, ATOMIC OPERATION 중에는 버스를 잠구게 된다.

  그러면, 다른 프로세서에서 CAS를 실행하려 해도 메모리를 가지고 올 수 없으니까.

모니터

뮤텍스, 기존 방법의 문제점

코딩 실수가 너무 잘 나고 디버깅이 힘들다. 어디에서 관리되는지 파악하기 어렵다.컴파일러도 못 잡아준다.

라이브니스

교착상태

우선순위 역전

• 내가 생각하는 거처럼, ABC가 필요한 대왕 프로세스가 있는데, B를 가져가는 좆밥 프로세스가 있어가지고 결국 우선순위가 바뀌는 현상.
• 요럴 때, 좆밥 프로세스에게 ABC프로세스가 우선순위를 상속해가지고 빨리빨리 처리되도록 한다.

ABA 문제