Microsoft MVP성태의 닷넷 이야기
.NET Framework: 2064. C# - Mutex와 Semaphore/SemaphoreSlim 차이점 [링크 복사], [링크+제목 복사]
조회: 5862
글쓴 사람
정성태 (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)
13267정성태2/21/20234097.NET Framework: 2097. C# - 비동기 소켓 사용 시 메모리 해제가 finalizer 단계에서 발생하는 사례파일 다운로드1
13266정성태2/20/20233687오류 유형: 848. .NET Core/5+ - Process terminated. Couldn't find a valid ICU package installed on the system
13265정성태2/18/20233666.NET Framework: 2096. .NET Core/5+ - PublishSingleFile 유형에 대한 runtimeconfig.json 설정
13264정성태2/17/20234969스크립트: 45. 파이썬 - uvicorn 사용자 정의 Logger 작성
13263정성태2/16/20233294개발 환경 구성: 666. 최신 버전의 ilasm.exe/ildasm.exe 사용하는 방법
13262정성태2/15/20234355디버깅 기술: 191. dnSpy를 이용한 (소스 코드가 없는) 닷넷 응용 프로그램 디버깅 방법 [1]
13261정성태2/15/20233565Windows: 224. Visual Studio - 영문 폰트가 Fullwidth Latin Character로 바뀌는 문제
13260정성태2/14/20233433오류 유형: 847. ilasm.exe 컴파일 오류 - error : syntax error at token '-' in ... -inf
13259정성태2/14/20233536.NET Framework: 2095. C# - .NET5부터 도입된 CollectionsMarshal
13258정성태2/13/20233414오류 유형: 846. .NET Framework 4.8 Developer Pack 설치 실패 - 0x81f40001
13257정성태2/13/20233530.NET Framework: 2094. C# - Job에 Process 포함하는 방법 [1]파일 다운로드1
13256정성태2/10/20234363개발 환경 구성: 665. WSL 2의 네트워크 통신 방법 - 두 번째 이야기
13255정성태2/10/20233680오류 유형: 845. gihub - windows2022 이미지에서 .NET Framework 4.5.2 미만의 프로젝트에 대한 빌드 오류
13254정성태2/10/20233584Windows: 223. (WMI 쿼리를 위한) PowerShell 문자열 escape 처리
13253정성태2/9/20234249Windows: 222. C# - 다른 윈도우 프로그램이 실행되었음을 인식하는 방법파일 다운로드1
13252정성태2/9/20233203오류 유형: 844. ssh로 명령어 수행 시 멈춤 현상
13251정성태2/8/20233634스크립트: 44. 파이썬의 3가지 스레드 ID
13250정성태2/8/20235466오류 유형: 843. System.InvalidOperationException - Unable to configure HTTPS endpoint
13249정성태2/7/20234135오류 유형: 842. 리눅스 - You must wait longer to change your password
13248정성태2/7/20233432오류 유형: 841. 리눅스 - [사용자 계정] is not in the sudoers file. This incident will be reported.
13247정성태2/7/20234297VS.NET IDE: 180. Visual Studio - 닷넷 소스 코드 디버깅 중 "Decompile source code"가 동작하는 않는 문제
13246정성태2/6/20233425개발 환경 구성: 664. Hyper-V에 설치한 리눅스 VM의 VHD 크기 늘리는 방법 - 두 번째 이야기
13245정성태2/6/20233897.NET Framework: 2093. C# - PEM 파일을 이용한 RSA 개인키/공개키 설정 방법파일 다운로드1
13244정성태2/5/20233369VS.NET IDE: 179. Visual Studio - External Tools에 Shell 내장 명령어 등록
13243정성태2/5/20234180디버깅 기술: 190. windbg - Win32 API 호출 시점에 BP 거는 방법 [1]
13242정성태2/4/20233634디버깅 기술: 189. ASP.NET Web Application (.NET Framework) 프로젝트의 숨겨진 예외 - System.UnauthorizedAccessException
1  2  3  4  5  6  7  8  9  10  11  12  [13]  14  15  ...