Skip to content

Commit ac3a111

Browse files
sigridjinethsigridjineth
authored
Merge pull request #68 from java-squid/han
운영체제 13회
2 parents 6e6562b + 7faea15 commit ac3a111

2 files changed

Lines changed: 127 additions & 0 deletions

File tree

‎operating-system/mutex-semaphore/han/README.md‎

Lines changed: 62 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,62 @@
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+
1. Mutex를 이용하는 환경은, 공유 자원에 하나의 소비자 (프로세스 혹은 스레드) 가 점유가 가능할 때 사용함.
51+
2. 엄밀하게 말하면 Mutex는 locking mechanism임. 즉 공유 자원을 잠그고, 열는 과정에 대한 것인듯.
52+
- 즉 자원에 동기적인 접근이 가능토록 하는 방법
53+
- 뮤텍스를 통해 공유자원을 잠근 소유자만, 뮤텍스를 통해 공유자원을 릴리즈 할 수 있다 (뮤텍스에 대한 소유권이 존재한다.)
54+
55+
3. Semaphore를 이용하는 환경은, 공유 자원에 여러 소비자 (여러 프로세스, 혹은 여러 스레드) 가 점유 가능할 때 사용하는 방법 인듯.
56+
4. Semaphore는 signaling mechanism 임 (소비자가 다른 소비자에게 알려주는 방식)
57+
- 어떤 자원을 점유하고 있는 소비자 중 한명이, 자신이 다 끝났으면 다른 대기하는 소비자에게 알려주는 방식인듯
58+
59+
# 참고
60+
- https://www.youtube.com/watch?v=oazGbhBCOfU
61+
- https://en.wikipedia.org/wiki/Semaphore_(programming)
62+
- https://www.geeksforgeeks.org/mutex-vs-semaphore/

‎operating-system/user-kernel-thread/han/README.md‎

Lines changed: 65 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,65 @@
1+
# Kernel 이란?
2+
![](https://upload.wikimedia.org/wikipedia/commons/thumb/8/8f/Kernel_Layout.svg/400px-Kernel_Layout.svg.png)
3+
4+
- OS에 핵심 부분인, 컴퓨터 프로그램을 의미.
5+
- 시스템의 모든 것을 제어할 수 있도록 도와주는 부분.
6+
- 항상 메모리에 상주하고 있으며, 하드웨어와 소프트웨어의 상호작용을 할 수 있도록 도와주는 핵심적인 인터페이스를 의미.
7+
8+
# Kernel level thread
9+
- 커널이 모든 프로세스, 스레드를 관리하는 방식을 의미 (스케쥴링등.. 모두 커널에서 관리)
10+
- 1개의 Process table, Thread table을 통해서 관리.
11+
- Context swiching이 자주 일어남.
12+
13+
## Advantages
14+
- 커널이 존재하는 모든 스레드의 정보를 알고 있기 때문에, 스케쥴러에서 적절하게 각 스레드별로 CPU 자원을 배분할 수 있음
15+
- non-blocking system call이 필요하지 않음.
16+
- 즉 만약 하나의 프로세스에 여러개의 스레드가 있다고 가정 하고 어떤 스레드(프로세스를 잡고 있는)가 Blocking 상태에 들어간다고 하여도, 다른 스레드에 작동에 영향을 주지 않음.
17+
- 커널이 그 프로세스에, 다른 스레드가 runnable한 상태임을 알고 있으므로, 스케쥴러에게 다른 스레드를 실행하라고 이야기 해줄듯.
18+
19+
## Disadbantages
20+
- 느리고 비율적임.
21+
- 모든 스레드가 커널에 의해 관리되므로 (System call), 이러한 관리는 비용이 큼.
22+
- 복잡도가 높음.
23+
- 커널이 모든 스레드의 정보를 알고 있어야 하므로,
24+
- 이러한 정보는 TCB(Thread Control Block) 에서 관리되는, 이러한 정보를 유지시키는 것이 상당한 오버헤드를 초래함.
25+
26+
# User level thread
27+
- 커널은 쓰레드의 존재를 알지 못함 (즉 관리하지 않는다.)
28+
- 커널은 단지 프로세스를 관리하는 테이블 (Process table) 만 가지고 있을뿐, 각각의 프로세스들이 스레드를 관리하는 테이블을 가지고 있음 (Thread table)
29+
- 즉 여러개의 스레드는 하나의 프로세스 (Many to One) 관리한다고 보면 됨.
30+
- Context swiching 이 커널 레벨 스레드 보다 적게 일어남.
31+
- 커널에 진입하지 않아도, 라이브러리 지원을 통해 스레드를 사용할 수 있게 함.
32+
- Ex) Jvm with thread
33+
34+
## Advantages
35+
- 하나의 프로세스가 여러개의 스레드를 관리하는 만큼, 스레드에 수행에 필요한 정보가 해당 프로세스에 모두 저장되어있음.
36+
- 그래서 빠르고 효율적임. (즉 context switching이 적어서)
37+
- 각각의 프로세스가 다른 스케쥴링 알고리즘을 사용하도록 커스텀 할 수 있음.
38+
39+
## Disadbantages
40+
- 어떤 프로세스에 여러 개의 스레드가 있다고 가정할 때,
41+
- 하나의 스레드가 커널을 호출 한다면 (System call)
42+
- 해당 프로세스 내, 모든 스레드가 중단될 것 (Blocking System)
43+
- 그래서 user level thread를 사용하기 위해서는 non-blocking system call이 필요함. (커널을 호출하더라도, blocking 되지 않도록..?)
44+
45+
# 정리
46+
![](https://examradar.com/wp-content/uploads/2019/02/threads-types.png)
47+
- (좌측) User level thread , (우측) Kernel level thread
48+
49+
- 유저 레벨에서 스레드를 관리하는 것이라는 뜻은,
50+
- 라이브러리등을 통해 하나의 프로세스에서 여러개의 스레드를 사용하게 만드는 것인듯.
51+
- 커널은 어떤 스레드가 있는지 모르고, 프로세스의 존재만 알고 있음.
52+
- 그래서 상대적으로 관리할 비용이 줄어들고 (프로세스만 관리하면 되니), 효율적으로 프로세스-스레드를 관리할 수 있도록 도와주는 측면이 있는듯.
53+
- 다만, 커널이 스레드를 관리하지 않는다는 건, 스레드의 상태를 잘못할 경우, 해당 프로세스는 blocked 상태로 변경되고, 다른 스레드들에 영향이 가는 결과를 초래할 수 있을듯.
54+
55+
- 커널 레벨에서 스레드를 관리하는 것은..
56+
- 커널이라는 프로그램이 모든 스레드의 정보를 알고 있어야 함.
57+
- 이 점이 굉장히 비용이 큰 사안일듯.
58+
- 다만, 커널이 관리해주므로, 프로세스가 죽는 block되는 사태는 벌어지지 않을듯.
59+
60+
# 참고
61+
- https://en.wikipedia.org/wiki/Kernel_(operating_system)
62+
- https://happy-chipmunk.tistory.com/entry/11-Multithreading2-Thread-%EC%9D%98-%EC%A0%81%EC%9A%A9-Userlevel-Threading-%EA%B3%BC-Kernellevel-Threading
63+
- https://www.geeksforgeeks.org/difference-between-user-level-thread-and-kernel-level-thread/
64+
- https://examradar.com/os-threads-different-types-thread-questions-answers/
65+
- https://colinch4.github.io/2020-02-02/%EC%BB%A4%EB%84%90%EB%A0%88%EB%B2%A8%EC%8A%A4%EB%A0%88%EB%93%9C-vs-%EC%9C%A0%EC%A0%80%EB%A0%88%EB%B2%A8%EC%8A%A4%EB%A0%88%EB%93%9C/

0 commit comments

Comments
 (0)