일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 |
- jdk #javac #jre #java standard library #javadoc #jar #java
- Mutual exclusion
- db
- 머신러닝 #ml #미분 #기본기
- featurescaling
- JetBrains
- 상호 배제
- 경쟁 조건
- 속성중요도
- 운영체제
- 11049
- featureimportances
- ML
- Mutex lock
- 다항회귀
- 머신러닝 #ml #기본기
- min-max
- 머신러닝 #ml #선형대수학 #기본기
- 에다 부스트
- 멀티 프로그래밍
- 디자인 패턴 #싱글톤
- gridsearch
- Kotlin
- 지니불순도
- cross_val_score
- bootstrapping
- ml
- 결정트리
- Java
- 코틀린
- Today
- Total
코딩하는 오리
[운영체제] 동기화 본문
프로세스 동기화
여러 프로세스가 공유하는 자원의 일관성을 유지하는 것
여러 프로세스가 서로 협력해 공유자원을 사용하는 상황에서 경쟁조건(race condition)이 발생하면 공유자원의 일관성이 깨진다. 이를 방지하기 위해 프로세스들이 공유자원을 사용할 때 프로세스에 대한처리 순서를 결정하는 것.
Race Condition(경쟁 조건)
공유되는 자원에서 두개 이상의 프로세스 혹은 스레드가 하나의 자원에 접근할 때 공유자원에 대한 접근 순서에 따라 실행 결과가 달라질 수 있는 상황
Critical Section(임계 영역)
Race Condition이 발생하지 않도록 한번에 하나의 프로세스만 접근할 수 있도록 보장해주어야하는 영역
3가지 조건을 만족해야한다
- Mutual Exclusion (상호배타) : 오직 한 쓰레드만 진입
- Progress (진행) : 진입 결정은 유한 시간 내에 결정 - 임계영역을 사용하고 있지 않다면 다른 프로세스가 접근할 수 있도록 한다
- Bounded Waiting (유한 대기) : 어느 쓰레드라도 유한 시간 내 진입 - 임계 영역 진입 횟수에 한계를 두어 같은 프로세스가 계속 독점하여 사용해 다른 프로세스들이 기아상태에 빠지지 않게 한다
mutual exclusion
임계 구역을 어느 시점에서 단지 한 개의 프로세스만이 사용할 수 있도록 하며, 다른 프로세스가 현재 사용 중인 임계 구역에 대하여 접근하려고 할 때 이를 금지하는 행위
프로세스 동기화 방법
mutex lock
- 프로세스는 임계 구역에 들어가기 전에 lock을 획득하고 나올 때는 lock을 반환해야 한다(화장실 열쇠)
- lock을 사용할 수 있다면 acquire()를 통해 lock을 호출, 다른 프로세스가 접근하지 못하게 lock은 사용할 수 없다가 lock을 반환할 때는 release() 호출
- busy waiting : 임계 구역에 들어가기 전 lock을 얻기 위해 acquire()에서 무한루프에 빠진다(spin lock). context switching을 하지 않고 로프를 돌며 재시도 하여 cpu cycle을 낭비하게 한다.
semaphore
- 여러 개의 프로세스 혹은 스레드가 임계 영역에 접근하는 것을 막는다. 동기화 대상이 하나 이상 가
- 프로세스간의 시그널(signal)을 주고 받기 위해 사용되는 정수값(= 리소스 상태를 나타내는 카운터)
- 프로세스가 임계영역에 접근시 wait()을 호출해 값이 감소하고, 임계영역을 나와 lock을 반납할 때 signal()을 호출해 값이 증가한다
- wait()과 signal() 함수에서 변경하는 S도 공유변수라 critical section 문제가 생길 수 있다. 커널과 하드웨어가 두 함수를 atomic exclusive하게 동작함을 보장해야 한다 -> 이를 위해 인터럽트를 금지해야한다
- semaphore가 0이 되면 모든 자원이 프로세스들에 의해 모두 사용중이라는 것을 의미하고, busy waiting 상태에 들어간다
- semaphore가 busy-waiting 문제를 해결하는 방법 : 임계 구역 진입을 위해 무한 루프를 돌며 대기하는 대신 프로세스를 중지시키고 waiting queue에 넣고, 어떤 프로세스가 임계 구역에서 나오면 signal() 함수로 waiting queue에 있는 프로세스를 ready queue로 이동한다.
monitor
- 세마포어의 경우 직접 프로그래머가 제어하기 때문에 오류가 난다. 이를 막기 위한 고급 언어 구조 중 하나
- 공유자원을 내부적으로 가지고 있어서 외부에 공개하지 않는다.(클래스의 private 접근자 변수와 유사, public 메스드를 통해서만 접근할 수 있다(
- 하나의 lock과 여러 condition variable(queue라고도 함)로 구성된다. lock을 이용해 여러 개의 스레드가 critical section에 접근하지 못하도록 제어
- 각 일반 instance에 존재하는 monitor를 이용하여 thread 사이의 동기화를 수행한다. wait()는 condition variable로 구현한다. notify()를 통해 condition variable에서 대기중인 임의의 하나의 thread를 깨우고, notifyAll()를 통해 대기중인 모든 thread를 깨울 수 있다.
mutex vs semaphore
세마포어는 뮤텍스가 될 수 있지만, 뮤텍스는 세마포어가 될 수 없다.
세마포어는 소유할 수 없으나 뮤텍스는 소유할 수 있고, 소유주가 그에 대한 책임을 진다
뮤텍스는 Locking 메커니즘으로 락을 걸은 스레드(소유주)만이 임계 영역을 나갈때 락을 해제할 수 있다. 하지만 세마포어는 Signaling 메커니즘으로 락을 걸지 않은 스레드도 signal을 사용해 락을 해제할 수 있다. 세마포어의 카운트를 1로 설정하면 뮤텍스처럼 활용할 수 있다.
mutex vs monitor
뮤텍스는 다른 프로세스(어플리케이션)간에 동기화 할 때 사용할 수 있다는 것이고, 모니터는 하나의 프로세스(어플리케이션) 내에 다른 스레드 간에 동기화 할 때 사용된다. 뮤텍스는 보통 운영체제 커널, 프레임워크, 라이브러리에 의해서 제공되는 반면 모니터는 프레임워크나 라이브러리 그 자체에서 제공된다. 따라서 뮤텍스는 무겁고 느리고, 모니터는 가볍고 빠르다
semaphore vs monitor
세마포어는 binary semaphore가 아니라 counting semaphore를 제공하는 반면 모니터는 개념적으로 binary semaphore만 가능하다.
Java에서는 모니터를 모든 객체에게 기본적으로 제공하고 있는 반면, C에서는 모니터를 사용할 수 없다.
세마포어는 실제로 카운터라는 변수값으로 프로그래머가 상호 배제나 오더링 목적으로 사용시 매번 값을 따로 지정해주어야하는 등 조금 번거롭다. 하지만 모니터는 이런 내용이 캡슐화되어있어서 개발자는 카운터 값을 1로 주냐 0으로 주냐 고민할 필요 없이 synchronized, wait(), notify()등의 키워드를 이용해 좀 더 편하게 동기화할 수 있다.
'운영체제' 카테고리의 다른 글
[운영체제] 운영체제, 컴퓨터의 요소 (0) | 2023.03.09 |
---|