세마포어 & 뮤텍스

[Tokwasp]

• 세마포어와 뮤텍스
  • 이진 세마포어와 뮤텍스의 차이에 대해 설명해 주세요.
  • Lock을 얻기 위해 대기하는 프로세스들은 Spin Lock 기법을 사용할 수 있습니다. 이 방법의 장단점은 무엇인가요? 단점을 해결할 방법은 없을까요?
  • 뮤텍스와 세마포어 모두 커널이 관리하기 때문에, Lock을 얻고 방출하는 과정에서 시스템 콜을 호출해야 합니다. 이 방법의 장단점이 있을까요? 단점을 해결할 수 있는 방법은 없을까요?

[JoisFe]

• 먼저 세마포어와 뮤텍스는 동기화 문제를 해결하기 위한 방법 중 하나입니다. (race condition 방지 Thread Safe #7 참고)

Mutex (뮤텍스)

• 1개의 process or thread 만이 공유 자원에 접근 가능하도록 하는 방법입니다.
• process or thread가 공유자원에 접근하면 lock 을 걸게 되고, 다른 process or thread는 공유자원에 접근할 수 없습니다.
• process (thread) 가 공유 자원의 사용이 끝나 방출할때 unlock 을 걸게 되면 이후 process (thread) 가 자원에 접근이 가능합니다.
• 정확히는 process (thread)가 critical section에 들어가기 전에 lock을 획득 -> 이후 빠져나올 때 lock 반환

장점

• 동시성 문제를 해결하는 방법 중 매우 간단하게 구현할 수 있습니다. (단순함)

단점

• 여러 Process (thread) 가 공유자원 접근을 원할 때 하나의 process(thread) 만이 접근가능하므로 블로킹 상태가 오래 걸려 오버헤드가 증가할 수 있습니다.

Semaphore (세마포어)

• process or thread 가 동시에 공유자원하고자 할 때, 특정 갯수 (s개)만이 접근할 수 있도록 접근 제어를 하는 방법입니다.
• s (semaphore) 값을 접근 허용할 수로 초기화
• s-- 를 하여 semaphore 값을 감소시킵니다. (자원 접근이 끝나고 방출 시에는 s++)
• s 값이 0이 되면 process or thread가 공유 자원에 접근하는 것을 막고 s가 다시 증가하면 접근을 허용합니다.

장점

• 여러 스레드가 자원에 동시에 접근해야하는 경우 유용
• s 값을 조절할 수 있어 s = 1 로 두어 mutex 처럼 사용 가능 등 유연함

단점

• 잘못되게 사용시 dead lock (교착상태 (데드락) #24 참고) 이 발생할 수 있습니다.
• 여러 semaphore 방식 조합하면 복잡할 수 있습니다.

Q) 세마포어와 뮤텍스의 차이에 대해 설명해주세요

• 두가지 방법 모두 공유자원에 대한 접근 제어를 하는 방법이지만 세마포어는 최대 n개 까지 process (thread) 가 공유자원에 접근 가능하도록 하는 방법이고, 뮤텍스는 하나의 Process (thread) 만이 공유자원에 접근 가능하도록 하는 방법입니다.
• 정리하자면 세마포어는 공유된 자원에 대한 접근을 제한하는 방법이라면, 뮤텍스는 공유된 자원에 동시 접근을 막는 방법입니다.
• 세마포어의 s의 값을 1로 하면 뮤텍스가 됩니다.
• 뮤텍스는 자원을 소유하고 있는 process (thread) 만이 뮤텍스를 해제할 수 있지만, 세마포어는 세마포어를 소유하지 않은 다른 process(thread) 가 세마포어를 해제할 수 있습니다.

Q) Lock을 얻기 위해 대기하는 프로세스들은 Spin Lock 기법을 사용할 수 있습니다. 이 방법의 장단점은 무엇인가요? 단점을 해결할 방법은 없을까요?

Spin Lock

• 다른 thread가 Lock을 소유하고 있을 때 Lock이 반환될 때 까지 지속적으로 확인하면서 (무한 루프) 기다리는 방법 입니다.
• Lock 획득 까지 해당 thread가 spin 하고 있는 방법 입니다.
• spin lock 경우 OS의 스케줄링 지원을 받지않으므로 해당 Thread에 대한 Context Switching이 발생하지 않는 특징이 있습니다.

장점

• Spin Lock을 얻기 위해 context switching을 발생시키지 않아 만약 Lock이 짧은 시간내에 해제 되는 케이스에 효율적입니다.
• 구현하는 방법이 간단합니다. (대기 중에 thread가 계속 실행 상태 유지하기때문)

단점

• lock 을 얻기 위해 대기하는 동안 thread가 계속해서 CPU를 소비하여 비효율적 입니다. (CPU의 자원을 낭비)
  • lock 획득을 위해 무한 루프를 토는 것이 CPU를 많이 소비
• 하나의 thread가 Lock을 오랫동안 가지고 있다면 다른 스레드들은 계속해서 Spin 하고 있는 상태라 매우 비효율 적입니다. => Busy Wating
  • starvation 발생 (CPU 스케줄링 #21 참고)

Busy Waiting

• 어떠한 특정 공유자원에 대하여 두 개 이상의 프로세스나 스레드가 그 이용 권한을 획득하고자 하는 동기화 상황에서 그 권한 획득을 위한 과정에서 일어나는 현상 입니다.
• 대부분의 경우에 Spin Lock과 이것을 동일하게 생각하지만, 엄밀히 말하자면 스핀락이 바쁜 대기 개념을 이용한 것 이라고 합니다.

Q) 뮤텍스와 세마포어 모두 커널이 관리하기 때문에, Lock을 얻고 방출하는 과정에서 시스템 콜을 호출해야 합니다. 이 방법의 장단점이 있을까요? 단점을 해결할 수 있는 방법은 없을까요?

장점

• System Call을 통해 커널에서 Lock의 상태를 관리하므로, 스레드 간 동기화가 안전하고 데이터 무결성을 보장합니다. (내부 동작을 신경 쓸 필요없이 시스템 콜을 통해 커널이 Lock 상태 관리하도록 함)

단점

• 사용자 공간에서 커널 공간으로 전환 시 Context Switching이 발생하여 오버헤드가 발생합니다.

• 단점의 해결 방법 중 하나로는 사용자 공간에서 Lock 관리를 하는 방법으로 대표적인 예시로 Spin Lock 이 있습니다.

• Spin Lock을 얻기 위해 context switching을 발생시키지 않기 때문에 특정한 상황 (이전에 설명)에서 효율적일 수 있습니다.

참고

• https://velog.io/@octo__/%EC%84%B8%EB%A7%88%ED%8F%AC%EC%96%B4Semaphore
• https://currygamedev.tistory.com/21
• https://hogwart-scholars.tistory.com/entry/OS-Spin-Lock-%EC%8A%A4%ED%95%80%EB%9D%BD%EC%97%90-%EB%8C%80%ED%95%B4-%EC%95%8C%EC%95%84%EB%B3%B4%EC%9E%90
• https://ko.wikipedia.org/wiki/%EB%B0%94%EC%81%9C_%EB%8C%80%EA%B8%B0

[jay200333]

이진 세마포어와 뮤텍스의 차이에 대해 설명해주세요.

✅ 답변

이진 세마포어

• 값을 0과 1만 가지고 있는 세마포어
• 상호 배제를 위해 신호 전달 메커니즘을 사용해서 잠금을 구현
• 세마포어가 0이면 잠겨있는 것이고, 1이면 잠금이 해제된 것

뮤텍스

• 상호 배제를 locking과 unlocking으로 제공
• 하나의 스레드만 전체 버퍼와 함께 작업 가능

차이점

이진 세마포어	뮤텍스
신호 전달 메커니즘 기반	잠금 메커니즘 기반
현재 스레드보다 우선순위가 높은 스레드가 바이너리 세마포어를 해제하고 잠글 수 있음	뮤텍스를 획득한 스레드는 크리티컬 섹션에서 나갈 때만 뮤텍스 해제 가능
wait() , signal() 에 따라 변경	값이 locked, unlocked 으로 수정
여러 개의 스레드가 동시에 이진 세마포어를 획득 가능	한 번에 하나의 스레드만 뮤텍스를 획득 가능
소유권 X	뮤텍스를 소유한 스레드만 잠금을 해제 가능하므로 소유권이 있음
다른 스레드/프로세스가 잠금 해제가 가능하기 때문에 뮤텍스보다 더 빠름	획득한 스레드만 잠금 해제가 가능하므로 바이너리 세마포어보다 느리다

---

Lock을 얻기 위해 대기하는 프로세스들은 Spin Lock 기법을 사용할 수 있습니다. 이 방법의 장단점은 무엇인가요? 단점을 해결할 방법은 없을까요?

✅ 답변
Spinlock : Race Condition 상황에서 Lock이 반환될 때까지, 즉 Critical section에 진입 가능할 때까지 프로세스가 재시도하며 대기하는 상태

장점

1. 문맥 교환에 필요한 CPU의 오버헤드를 줄일 수 있다.
2. 락의 획득이 빠르다. (무한 루프를 통해 계속 반복해서 락을 확인하기때문)

단점

1. Busy waiting : 스핀락의 획득을 위해 CPU의 오버헤드가 발생할 수 있다. (무한루프를 돌면서 CPU를 계속 사용)
2. Starvation : 특정 스레드나 프로세스가 공유 자원을 오랫동안 점유하는 경우 다른 스레드들이 대기 상태에 갇힐 수 있다.

스핀락은 스레드나 프로세스의 경합 상황이 짧을 때 (임계 구역에서의 작업이 빠르게 이루어질 때) 유용하다.

→ 스핀락의 무한 루프 덕분에 락의 획득과 반환이 빨라 실행 속도도 빨라지고, 문맥 교환이 생략되기 때문에 CPU의 오버헤드도 줄어든다.

스핀락은 여러 개의 CPU 코어가 존재할 때 유용하다.

→ 사용하지 않는 CPU 코더에서 스핀락을 통해 대기하다가 바로 락을 획득할 수 있다.

→ 경합 상황이 길거나 싱글 CPU인 경우에는 뮤텍스, 세마포어가 더 괜찮은 것 같다.

---

뮤텍스와 세마포어 모두 커널이 관리하기 때문에, Lock을 얻고 방출하는 과정에서 시스템 콜을 호출해야 합니다. 이 방법의 장단점이 있을까요? 단점을 해결할 수 있는 방법은 없을까요?

✅ 답변

장점

• 커널이 자원을 관리하므로 데드락, Race Condition 등의 발생 가능석이 적음
• IPC에서도 안정적으로 사용 가능
• User 모드 락은 주로 스레드간 동기화에 한정되지만, 커널 락은 범용적이다.
• 커널이 직접 관리하기 때문에 락을 대기 중인 스레드나 프로세스를 효율적으로 스케줄링 할 수 있다.
• CPU 자원을 효율적으로 사용

단점

• 시스템 콜 호출 시 유저 모드 ↔ 커널 모드 전환이 발생하여 오버헤드가 크다.
• 락의 획득과 해제 시에도 문맥 전환 비용이 발생
• 단순한 동기화 작업에도 커널이 개입하므로 성능 저하 발생
• 단순하고 빈번한 임계 구역에서 비효율적

해결 방법

• 유저 모드 락 사용(Spin Lock) → 커널 개입 최소화
• Lock-Free / Wait-Free 알고리즘
  • 락 자체를 사용하지 않고 CAS 등의 원자적 연산을 통해 동시성 제어

[Tokwasp]

❓ 이진 세마포어와 뮤텍스의 차이에 대해 설명해 주세요.

🌱 [ 세마포어 ]

• 하나 이상의 프로세스 / 스레드가 임계영역에 접근 가능 하도록 하는 장치
• 순서를 제어 할때도 사용 된다.

🌱 [ 뮤텍스 ]

• 하나의 프로세스 / 스레드가 임계영역에 접근 가능 하도록 하는 장치
• 속성에 우선 순위 상속이 있다.

• 만약 우선순위가 낮은 프로세스가 락을 획득 시 우선순위가 높은 프로세스가 작업을 할 수 없는 현상
• 뮤텍스는 Priority inheritance 속성을 통해 우선 순위를 높여 작업을 빨리 처리할 수 있다.

-> 결론 : 뮤텍스는 상호배제를 위해서, 세마포어는 실행순서 동기화가 필요한 경우 권장 합니다.

❓ Lock을 얻기 위해 대기하는 프로세스들은 Spin Lock 기법을 사용할 수 있습니다.

이 방법의 장단점은 무엇인가요? 단점을 해결할 방법은 없을까요?

🌱 [ 스핀 락 ] : 락을 얻을때 까지 락 획득을 반복 하는 행위

[ 장점 ] : 멀티코어 환경에서 임계영역의 작업이 컨텍스트 스위칭 보다 빨리 끝난다면 스핀락이 뮤텍스보다 이점이 있다.

• 싱글코어에서는 스핀락으로 락을 얻을려면 누군가가 락을 해제 해야한다.
• 그러면 컨텍스트 스위칭을 통해 락을 반납하고 다시 컨텍스트 스위칭을 통해 락을 획득해야 한다.

[ 단점 ] : 계속 해서 락을 획득 했는지 확인 하기 때문에 CPU가 낭비 된다.

• 이에 대한 방법이 뮤텍스 이다. ( 락을 획득 시도 하고 없다면 큐에서 대기 )

❓ 뮤텍스와 세마포어 모두 커널이 관리하기 때문에, Lock을 얻고 방출하는 과정에서 시스템 콜을 호출해야 합니다.

이 방법의 장단점이 있을까요? 단점을 해결할 수 있는 방법은 없을까요?

[ 장점 ] :

• 안정성 : 커널에서 관리 되기 때문에 매커니즘이 안정적이고 신뢰성 있다.
• 공정성 : 커널은 세마포어 등의 기법을 통해 공정한 자원 분배를 보장 한다.

[ 단점 ] :

• 오버헤드 : 시스템 콜은 사용자 모드 -> 커널모드 전환이 반복되며 오버헤드가 발생 한다.
• 컨텍스트 스위칭 : 락을 얻기 위해 블록될 경우, 컨텍스트 스위칭 비용이 발생하여 성증 저하가 발생 할 수 있다.

[ 해결 방안 ] :

• 스핀락 : 간단한 경우 스핀락을 사용 하면 된다.
• 베리어 락 : 사용자 모드에서 구현된 베리어를 사용하여 특정 조건이 만족될때까지 기다린다. 시스템 콜의 빈도를 줄일수 있다.
• 락 분할 : 락을 세분화 하여 여러 락으로 분리하여 경합을 줄인다.

[JoisFe]

뮤텍스는 뮤텍스를 소유한 process만이 뮤텍스를 해제할 수 있다.
세마포어는 세마포어를 소유하지 않은 다른 process(thread) 가 세마포어를 해제할 수 있습니다.

--> 이로 인해 이진 뮤텍스 방식은 순서제어에 사용할 수 없지만 세마포어는 순서제어에 사용할 수 있군요.