일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 | 31 |
- SeSAC
- SRP
- CoreBluetooth
- MainScheduler
- SwiftUI
- DynamicMemberLookup
- swift
- cleanarchitecture
- combine
- DispatchQueue
- MainScheduler.Instance
- DiffableDataSource
- 명품cppProgramming c++
- MethodSwilzzling
- 등굣길
- 프로그래머스
- RaceCondition
- DependencyInjection
- GCD
- IOS
- gitflow
- rxswift
- 오픈채팅방
- Realm
- leetcode
- 청년취업사관학교
- GIT
- data_structure
- MainScheduler.asyncInstance
- 코테
- Today
- Total
Do.
Thread - Semaphores vs Mutexes 본문
소개
두 개념 모두 생호 배제를 목적으로 한다는 것은 동일하나 이전글의 출력문을 봐서 알겠지만 다른 양상을 보입니다. 어떤 차이에 의해서 그러한 현상이 발생할까요? 이번에는 단골 질문 중 하나인 Semaphore와 Mutex의 차이에 대해서 알아보려고 합니다.
Semaphores
우선 Semaphore는 P(wait)와 V(signal)로 이루어 져 있습니다. wait 연산은 Semaphore의 값을 감소시키고, signal은 값을 증가 시킵니다. Semaphore의 값이 0일 때, wait 연산을 수행하는 모든 프로세스는 다른 프로세스가 signal 연산을 수행할 때까지 차단되게 됩니다. 이전글에서 설명했었죠?
즉 Semaphore는 사실 정수와 같습니다. 단순히 숫자를 증가시키냐 감소시키냐 와 같다는 것이죠, 해당 정수를 기반으로 Ciritical Section에서 발생하는 공유 자원에 대한 접근을 관리합니다.
Semaphore는 두가지 타입이 있습니다.
- Binary Semaphore
- 기능적으로는 Mutex와 동일하다고 볼 수 있습니다. 0과 1만 존재하기 때문이죠
- Counting Semaphore
- 접근에 대한 제한하는 수를 설정 가능합니다.
Mutexes
Swift에서는 NSLock, NSRecursiveLock, NSConditionLock이 존재하는데, 이것들이 Mutex와 완전히 동일한가? 에 대하여 “그렇다” 라고 서술되어 있는 공식 문서를 보지 못해서 확실하지는 않지만, Mutex의 개념인 Lock, Unlock 연산을 똑같이 사용한다는 것입니다.
Semaphore와는 달리 값을 증가 시키고 감소 시키는 개념이 아니라 잠그고, 푸는 로직이기 때문에 두번 잠궜다 한번 풀고 이런 개념이 존재하지 않습니다.
차이
그렇다면 Semaphore와 Mutex의 차이점을 설명할 수 있을 것 같습니다.
결정적으로 Mutex는 Lock을 한 주체가 Unlock을 할 수 있다는 부분입니다. 화장실 문잠그고 들어간 사람이 직접 문을 열고 나오는 것과 같죠, 직관적이고 쉽죠? 하지만 잘못 사용하게 되면 크리티컬 섹션에 진입 후 스레드가 쉬는 상태이거나, 다른 우선 순위가 높은 작업이 있는데 앞서 스레드로 인해 섹션이 잠기는 바람에 작업자체가 중단될 수 있고, CPU 주기가 낭비될 수 있습니다.
반면에 Semaphore는 여러 스레드가 동시에 크리티컬 섹션에 액세스 할 수 있도록 해줍니다. 이로 인해 훨씬 더 유연하게 Thread Safe 환경을 만들 수 있습니다.
하지만 Semaphore는 우선순위 역전이 있습니다. 스케줄링에 의해 언제든지 다른 스레드가 와서 자기 할일 하고 나갈 수 있다는 것이죠, 이 때문에 동시적인 작업 수행이 더 도드라져 보입니다.
또 Semaphore는 여러 스레드에서 접근이 가능하기 때문에 Deadlock이 발생할 수도 있습니다. 주의해서 관리할 필요가 있죠. (사실 별 이상한 방법으로 사용하지 않는이상…)
그러면 Binary Semaphore는 Mutex와 완전히 동일합니까? 라고 했을 때는 어떨까요?
Binary Semaphore라고 해도 여전히 wait과 signal을 다른 스레드에서 수행할 수 있기 때문에 잘못 사용한다면 Dead Lock, Priority Inversion은 여전히 발생할 수 있습니다.
결론
Binary Semaphore보다는 Mutex를 선택하는 것이 더 옳은 선택처럼 보일 수도 있습니다. 그러나 반대로 잘 관리하고 사용만 할 수 있다면 Mutex의 단점을 보완할 수 있는 방법이기 때문에 결론은 적재적소에 잘 사용할 수 있도록 둘간의 차이점을 이해하는것이 중요할 것 같습니다.
# Reference
https://www.geeksforgeeks.org/difference-between-binary-semaphore-and-mutex/
'General Dev' 카테고리의 다른 글
Swift 단위테스트 자동화 xcresult를 junit.xml 변환하기 (0) | 2023.09.10 |
---|---|
Race Condition / Thread Safe (0) | 2023.06.26 |
iOS 개발자 부트캠프 - SeSAC(청년취업사관학교) (0) | 2023.05.03 |
UML(Unified Modeling Language) - feat. Class Diaphragm (0) | 2022.11.15 |
Architecture - Single Responsibility Principle(SRP) (2) | 2022.09.14 |