Skip to content

Commit 4bb119a

Browse files
committed
Add mutex-semaphore
1 parent ffacebf commit 4bb119a

File tree

1 file changed

+52
-0
lines changed
  • operating-system/mutex-semaphore/han

1 file changed

+52
-0
lines changed
Lines changed: 52 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,52 @@
1+
# Mutex
2+
- Mutual (mut) + Exclusion (ex) 의 합성어
3+
- 상호 배제
4+
- 여러 스레드를 실행하는 환경, 자원에 대한 접근을 강제하기 위한 동기화 방식
5+
6+
> Mutual Exclusion
7+
8+
- 하나의 프로세스가 공유 자원을 사용할 때, 다른 프로세스가 해당 자원에 접근하지 못하도록 하는 것.
9+
- 즉 공유 자원에 점유할 수 있는 프로세스, 스레드의 수는 한 개라는 의미..?
10+
- 어떻게 접근하지 못하도록 할까?
11+
- 어떻게 다른 프로세스가 공유 자원이 사용할 수 있는지, 없는지 알 수 있을까?
12+
13+
> 작동 방식
14+
15+
1. Lock
16+
- 공유 자원에는 `Boolean Lock` 변수가 있음
17+
- Lock = true을 한 스레드만 Lock을 풀 수 있음.
18+
- 그리고 공유자원을 사용하려하고는 스레드들을 위한 **대기큐**가 있음.
19+
- 현재 공유자원을 점유하고 있는 스레드가 있을 경우, 이 자원에 접근하는 스레드들을 `blocking` 시키고, 대기큐에 적재하여 `sleeping` 상태로 변경해둠.
20+
- 공유 자원의 Lock 변수가 false라면, 비어져 있다면, 대기큐에서 하나 깨워서 점유하게 만듬.
21+
22+
2. SpinLock
23+
- Busy-wating 방식
24+
- 공유자원에 접근하는 스레드는, 계속 공유 자원에게 자리가 있는지 계속 물어보는 방식 (대기큐가 없다)
25+
- 그럼 비효율적
26+
- 왜?
27+
- 해당 공유자원을 점유하고 있는 스레드 뿐만 아니라, 물어보는 다른 스레드의 요청까지 처리해줘야 하므로..
28+
- 그럼 어떤 상황에 위 방식을 사용할까?
29+
- 대기큐를 사용하는 방식보다, 공유자원에게 물어보는 시간이 짦다면.. 굳이 대기큐를 사용하지 않아도 될듯. (컨텍스트 스위칭 시간이 짦으면..)
30+
- 다른 스레드의 질의를 처리할 여유가 있을 때 (멀티 프로세스 일 때)
31+
32+
33+
# Semaphore
34+
- 다수의 프로세스, 스레드가 여러 개의 공유자원에 대한 접근을 제한하는 방법
35+
- Mutex랑은 다르게, 여러 프로세스, 스레드가 공유자원에 접근할 수 있다는 차이점이 있음 (뮤텍스는 하나의 스레드가 공유자원에 접근할 때의 접근을 제어하는 방식을 이야기 하는듯)
36+
- P(wait), V(signal)
37+
- 변수는 정수형 (뮤텍스는 boolean... 변수)
38+
39+
> 작동 방식
40+
41+
1. Sleep - wait
42+
- 대기큐 사용
43+
- 공유 자원에 자리가 생기면, 대기큐에서 잠자고 있는 스레드를 꺠우는 방식
44+
45+
2. SpinLock
46+
- Busy - wating 방식
47+
48+
# 정리
49+
# 참고
50+
- https://www.youtube.com/watch?v=oazGbhBCOfU
51+
- https://en.wikipedia.org/wiki/Semaphore_(programming)
52+
- https://www.geeksforgeeks.org/mutex-vs-semaphore/

0 commit comments

Comments
 (0)