Microsoft MVP성태의 닷넷 이야기
.NET Framework: 2064. C# - Mutex와 Semaphore/SemaphoreSlim 차이점 [링크 복사], [링크+제목 복사],
조회: 7146
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
(연관된 글이 1개 있습니다.)
(시리즈 글이 5개 있습니다.)
.NET Framework: 2064. C# - Mutex와 Semaphore/SemaphoreSlim 차이점
; https://www.sysnet.pe.kr/2/0/13156

.NET Framework: 2065. C# - Mutex의 비동기 버전
; https://www.sysnet.pe.kr/2/0/13157

닷넷: 2216. C# - SemaphoreSlim 사용 시 주의점
; https://www.sysnet.pe.kr/2/0/13555

닷넷: 2217. C# - 최댓값이 1인 SemaphoreSlim 보다 Mutex 또는 lock(obj)를 선택하는 것이 나은 이유
; https://www.sysnet.pe.kr/2/0/13558

디버깅 기술: 195. windbg 분석 사례 - Semaphore 잠금으로 인한 Hang 현상 (닷넷)
; https://www.sysnet.pe.kr/2/0/13560




C# - Mutex와 Semaphore/SemaphoreSlim 차이점

그러고 보니, 제 블로그에서 MutexSemaphore에 대해 다룬 적이 거의 없었군요. ^^; 이참에 한번 정리해보겠습니다.

두 개 모두 동기화 개체지만, 사실 Mutex는 Semaphore의 특별한 사례에 속합니다. 즉, Semaphore를 이용하면 Mutex처럼 구현하는 것도 가능합니다.

예를 들어 볼까요?

namespace mutex_semaphore
{
    internal class Program
    {
        static Mutex _m = new Mutex(false);

        static void Main(string[] args)
        {
            Task t1 = CreateNewTask(1);
            Task t2 = CreateNewTask(2);

            t1.Wait();
            t2.Wait();
            Console.WriteLine("Main-end");
        }

        private static Task CreateNewTask(int workId)
        {
            return Task.Run(() =>
            {
                _m.WaitOne();
                Console.WriteLine($"{DateTime.Now:T} [{workId}]: Sleep-before");
                Thread.Sleep(2000);
                Console.WriteLine($"{DateTime.Now:T} [{workId}]: Sleep-after");
                _m.ReleaseMutex();
            });
        }
    }
}

/* 출력 결과
오전 11:20:54 [2]: Sleep-before
오전 11:20:56 [2]: Sleep-after
오전 11:20:56 [1]: Sleep-before
오전 11:20:58 [1]: Sleep-after
Main-end
*/

위의 프로그램은 Task.Run 내부의 작업에 대해 Mutex로 WaitOne/ReleaseMutex로 동기화를 했기 때문에 단 하나의 스레드만 내부 코드를 실행할 수 있습니다.

동일한 효과를 세마포어를 이용하면 다음과 같이 구현할 수 있습니다.

namespace mutex_semaphore
{
    internal class Program
    {
        static Semaphore _smp = new Semaphore(1, 1);

        static void Main(string[] args)
        {
            // ...[생략]...
        }

        private static Task CreateNewTask(int workId)
        {
            return Task.Run(() =>
            {
                _smp.WaitOne();
                Console.WriteLine($"{DateTime.Now:T} [{workId}]: Sleep-before");
                Thread.Sleep(2000);
                Console.WriteLine($"{DateTime.Now:T} [{workId}]: Sleep-after");
                _smp.Release();
            });
        }
    }
}

/* 출력 결과
오전 11:20:05 [1]: Sleep-before
오전 11:20:07 [1]: Sleep-after
오전 11:20:07 [2]: Sleep-before
오전 11:20:09 [2]: Sleep-after
Main-end
*/

그런데, 이렇게 동일하게 구현할 수 있어도 그 둘 간의 재미있는 차이점이 하나 있습니다.




그 차이점이란, 바로 "재진입 가능성"입니다. 즉, Lock과 Thread에 결합이 있느냐가 문제가 됩니다.

우선, Mutex는 그것을 진입한 스레드, 즉 WaitOne을 호출한 스레드가 동일하게 ReleaseMutex를 호출해야 합니다. 그렇지 않으면,

static Mutex _m = new Mutex(false);

static void Main(string[] args)
{
    _m.WaitOne();
    CreateReleaseTask(1).Wait();
}

private static Task CreateReleaseTask(int workId)
{
    return Task.Run(() =>
    {
        Console.WriteLine($"{DateTime.Now:T} [{workId}]: releasing");
        try
        {
            _m.ReleaseMutex();
            Console.WriteLine($"{DateTime.Now:T} [{workId}]: released");
        }
        catch (Exception e)
        {
            Console.WriteLine(e.Message);
        }
    });
}

/* 출력 결과
오전 11:40:58 [1]: releasing
Object synchronization method was called from an unsynchronized block of code.
*/

위와 같이 ReleaseMutex에서 예외가 발생합니다. 이런 특징은 같은 스레드 내에서 WaitOne을 잠금 없이 다시 진입하는 것을 허용합니다. 대신 lock-count와 release-count 횟수를 일치시켜야만 lock이 풀립니다. 아래는 그에 대한 실행 예제를 보여줍니다.

_m.WaitOne(); // mutex lock 진입
_m.WaitOne(); // 같은 스레드에서 mutex lock 재진입 가능

_m.ReleaseMutex(); // 같은 스레드에서 release했지만, 여전히 lock 상태
Console.WriteLine($"{DateTime.Now:T} : new Task");
Task t1 = CreateNewTask(1);

Thread.Sleep(5000);
_m.ReleaseMutex(); // 같은 스레드에서 WaitOne 호출과 짝을 맞춘 Release 호출 시 비로소 lock 해제
t1.Wait();

/* 출력 결과
오전 11:44:37 : new Task
오전 11:44:42 [1]: Sleep-before
오전 11:44:44 [1]: Sleep-after
*/




반면 세마포어는 Lock과 Thread의 결합이 없습니다. 그래서, 서로 다른 스레드에서 lock을 잠그고 해제하는 것이 가능해 다음과 같은 예제가 잘 동작합니다.

_smp.WaitOne();
var t1 = CreateNewTask(1);
CreateReleaseTask(2).Wait();

t1.Wait();

private static Task CreateReleaseTask(int workId)
{
    return Task.Run(() =>
    {
        Console.WriteLine($"{DateTime.Now:T} [{workId}]: releasing");
        // ...[생략]...
        _smp.Release();
        Console.WriteLine($"{DateTime.Now:T} [{workId}]: released");
        // ...[생략]...
    });
}

/* 출력 결과
오후 12:00:21 [2]: releasing
오후 12:00:21 [2]: released
오후 12:00:21 [1]: Sleep-before
오후 12:00:23 [1]: Sleep-after
*/

보는 바와 같이 Main 스레드에서 lock을 획득 후 CreateNewTask로 해당 lock이 필요한 작업을 스레드로 시작한 다음, lock 해제를 다른 스레드에서 할 수 있어 CreateNewTask의 작업이 lock을 획득하면서 진행하고 있습니다.

이로 인해, 동일한 스레드에서 lock을 획득 시 주의해야 합니다. Mutex에서는 가능했던 다음의 코드가,

static Semaphore _smp = new Semaphore(1, 1);

static void Main(string[] args)
{
    _smp.WaitOne(); // 여기서의 잠금 한 번은 성공적으로 획득했지만,
    _smp.WaitOne(); // hang!!!! 같은 스레드에서 Semaphore lock 재진입 불가능
    Console.WriteLine("Main-end");
}

Semaphore에서는 WaitOne을 호출할 때마다 "현재 스레드가 이미 lock을 소유하고 있다는" 연관이 없으므로 매번 필요한 lock을 소유하는 식이어서, 위의 코드에서 두 번째 WaitOne은 무한 대기를 하는 현상이 나옵니다.




마지막으로, SemaphoreSlim과 Semaphore의 차이점은 뭘까요? 이에 대해서는 공식 문서에서 잘 설명하고 있습니다.

Semaphore and SemaphoreSlim
; https://learn.microsoft.com/en-us/dotnet/standard/threading/semaphore-and-semaphoreslim

그러니까, Semaphore와 Mutex는 운영체제가 제공하는 동기화 개체를 재사용하는 반면 SemaphoreSlim은 닷넷 런타임에서 스스로 구현한 개체입니다. 따라서 이름에서 유추할 수 있듯이 slim하기 때문에 성능 면에서 Semaphore보다 SemaphoreSlim이 더 낫습니다.

둘 간의 극명한 차이점은, Semaphore는 그것에 "이름"을 부여해 초기화하는 것이 가능합니다.

static Semaphore _named_smpp = new Semaphore(1, 1, "named.sem");

이렇게 주어진 이름으로, 서로 다른 프로세스 간에 해당 이름으로 동일한 Semaphore를 열 수 있습니다. 즉, inter-process 수준으로 동기화를 제공하는 것입니다.

당연히 닷넷 런타임 내에서 구현한 SemaphoreSlim은 운영체제의 도움을 받지 않으므로 프로세스 간 동기화에는 사용할 수 없습니다. (애당초 이름을 받는 생성자가 없습니다.)

그렇다면 "unnamed Semaphore"와 "SemaphoreSlim"의 차이는 뭘까요?

닷넷 프레임워크 시절에는, "다중 AppDomain"을 이용해 하나의 EXE 프로세스에서 여러 닷넷 응용 프로그램이 올라올 수 있었는데요, 그런 상황에서 "unnamed Semaphore"를 사용하면 inter-appdomain 간에 동기화가 가능했습니다. 반면 SemaphoreSlim은 AppDomain 내에서의 동기화만 가능하고.

따라서, 닷넷 코어/5+에서는 "다중 AppDomain"을 지원하지 않으므로 결국 그 둘 간의 선택 차이가 없어졌습니다. 어차피 단일 AppDomain이기 때문에, 기왕이면 SemaphoreSlim의 사용을 (성능상으로도 이점이 있으므로) 권장합니다. (달리 말해, 이제는 unnamed인 경우 Semaphore를 쓸 이유가 없어졌습니다.)

그리고 약간 혼란스럽지만, 다음과 같은 내용도 있습니다.

However, it also provides lazily initialized, kernel-based wait handles as necessary to support waiting on multiple semaphores. SemaphoreSlim also supports the use of cancellation tokens, but it does not support named semaphores or the use of a wait handle for synchronization.


그러니까, wait handle을 지원하지 않는다는 것인데 다중 세마포어의 대기를 할 때는 wait handle을 제공한다고 합니다. ^^;

(첨부 파일은 이 글의 예제 코드를 포함합니다.)




이 정도면, 대충 Mutex와 Semaphore/SemaphoreSlim에 대한 차이점은 정리가 된 것 같습니다. 참고로, 아주 관련이 있는 것은 아니지만 다음의 글들도 읽어보시면 도움이 될 것입니다. ^^

Named 동기화 개체 생성 시 System.UnauthorizedAccessException 예외 발생하는 경우
; https://www.sysnet.pe.kr/2/0/1170

.NET 코드 - 단일 Process 실행
; https://www.sysnet.pe.kr/2/0/967




[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]

[연관 글]






[최초 등록일: ]
[최종 수정일: 2/14/2024]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 




[1]  2  3  4  5  6  7  8  9  10  11  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
13632정성태5/20/2024296Phone: 17. C# MAUI - Android 내에 Web 서비스 호스팅
13631정성태5/19/2024334Phone: 16. C# MAUI - /Download 등의 공용 디렉터리에 접근하는 방법
13630정성태5/19/2024495닷넷: 2263. C# - Thread가 Task보다 더 빠르다는 어떤 예제(?)
13629정성태5/18/2024597개발 환경 구성: 710. Android - adb.exe를 이용한 파일 전송
13628정성태5/17/2024549개발 환경 구성: 709. Windows - WHPX(Windows Hypervisor Platform)를 이용한 Android Emulator 가속
13627정성태5/17/2024560오류 유형: 903. 파이썬 - UnicodeEncodeError: 'ascii' codec can't encode character '...' in position ...: ordinal not in range(128)
13626정성태5/15/2024800Phone: 15. C# MAUI - MediaElement Source 경로 지정 방법파일 다운로드1
13625정성태5/14/20241187닷넷: 2262. C# - Exception Filter 조건(when)을 갖는 catch 절의 IL 구조
13624정성태5/12/20241342Phone: 14. C# - MAUI에서 MediaElement 사용파일 다운로드1
13623정성태5/11/20241441닷넷: 2261. C# - 구글 OAuth의 JWT (JSON Web Tokens) 해석파일 다운로드1
13622정성태5/10/20241394닷넷: 2260. C# - Google 로그인 연동 (ASP.NET 예제)파일 다운로드1
13621정성태5/10/20241247오류 유형: 902. IISExpress - Failed to register URL "..." for site "..." application "/". Error description: Cannot create a file when that file already exists. (0x800700b7)
13620정성태5/9/20241310VS.NET IDE: 190. Visual Studio가 node.exe를 경유해 Edge.exe를 띄우는 경우
13619정성태5/7/20241285닷넷: 2259. C# - decimal 저장소의 비트 구조파일 다운로드1
13618정성태5/6/20241393닷넷: 2258. C# - double (배정도 실수) 저장소의 비트 구조파일 다운로드1
13617정성태5/5/20241343닷넷: 2257. C# - float (단정도 실수) 저장소의 비트 구조파일 다운로드1
13616정성태5/3/20241288닷넷: 2256. ASP.NET Core 웹 사이트의 HTTP/HTTPS + Dual mode Socket (IPv4/IPv6) 지원 방법파일 다운로드1
13615정성태5/3/20241191닷넷: 2255. C# 배열을 Numpy ndarray 배열과 상호 변환
13614정성태5/2/20241150닷넷: 2254. C# - COM 인터페이스의 상속 시 중복으로 메서드를 선언
13613정성태5/1/20241218닷넷: 2253. C# - Video Capture 장치(Camera) 열거 및 지원 포맷 조회파일 다운로드1
13612정성태4/30/20241209오류 유형: 902. Visual Studio - error MSB3021: Unable to copy file
13611정성태4/29/20241239닷넷: 2252. C# - GUID 타입 전용의 UnmanagedType.LPStruct - 두 번째 이야기파일 다운로드1
13610정성태4/28/20241258닷넷: 2251. C# - 제네릭 인자를 가진 타입을 생성하는 방법 - 두 번째 이야기
13609정성태4/27/20241352닷넷: 2250. PInvoke 호출 시 참조 타입(class)을 마샬링하는 [IN], [OUT] 특성파일 다운로드1
13608정성태4/26/20241407닷넷: 2249. C# - 부모의 필드/프로퍼티에 대해 서로 다른 자식 클래스 간에 Reflection 접근이 동작할까요?파일 다운로드1
[1]  2  3  4  5  6  7  8  9  10  11  12  13  14  15  ...