Microsoft MVP성태의 닷넷 이야기
.NET Framework: 2064. C# - Mutex와 Semaphore/SemaphoreSlim 차이점 [링크 복사], [링크+제목 복사],
조회: 11829
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
(연관된 글이 1개 있습니다.)
(시리즈 글이 7개 있습니다.)
.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

닷넷: 2284. C# - async 메서드에서의 lock/Monitor.Enter/Exit 잠금 처리
; https://www.sysnet.pe.kr/2/0/13697

닷넷: 2285. C# - async 메서드에서의 System.Threading.Lock 잠금 처리
; https://www.sysnet.pe.kr/2/0/13698




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




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

[연관 글]






[최초 등록일: ]
[최종 수정일: 7/26/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)
13541정성태1/29/20246389VS.NET IDE: 188. launchSettings.json의 useSSL 옵션
13540정성태1/29/20246637Linux: 69. 리눅스 - "Docker Desktop for Windows" Container 환경에서 IPv6 Loopback Address 바인딩 오류
13539정성태1/26/20246432개발 환경 구성: 703. Visual Studio - launchSettings.json을 이용한 HTTP/HTTPS 포트 바인딩
13538정성태1/25/20246916닷넷: 2211. C# - NonGC(FOH) 영역에 .NET 개체를 생성파일 다운로드1
13537정성태1/24/20247221닷넷: 2210. C# - Native 메모리에 .NET 개체를 생성파일 다운로드1
13536정성태1/23/20246845닷넷: 2209. .NET 8 - NonGC Heap / FOH (Frozen Object Heap) [1]
13535정성태1/22/20247077닷넷: 2208. C# - GCHandle 구조체의 메모리 분석
13534정성태1/21/20246993닷넷: 2207. C# - SQL Server DB를 bacpac으로 Export/Import파일 다운로드1
13533정성태1/18/20247094닷넷: 2206. C# - TCP KeepAlive의 서버 측 구현파일 다운로드1
13532정성태1/17/20247137닷넷: 2205. C# - SuperSimpleTcp 사용 시 주의할 점파일 다운로드1
13531정성태1/16/20247193닷넷: 2204. C# - TCP KeepAlive에 새로 추가된 Retry 옵션파일 다운로드1
13530정성태1/15/20246286닷넷: 2203. C# - Python과의 AES 암호화 연동파일 다운로드1
13529정성태1/15/20246352닷넷: 2202. C# - PublishAot의 glibc에 대한 정적 링킹하는 방법
13528정성태1/14/20246592Linux: 68. busybox 컨테이너에서 실행 가능한 C++, Go 프로그램 빌드
13527정성태1/14/20246547오류 유형: 892. Visual Studio - Failed to launch debug adapter. Additional information may be available in the output window.
13526정성태1/14/20246721닷넷: 2201. C# - Facebook 연동 / 사용자 탈퇴 처리 방법
13525정성태1/13/20246148오류 유형: 891. Visual Studio - Web Application을 실행하지 못하는 IISExpress
13524정성태1/12/20246468오류 유형: 890. 한국투자증권 KIS Developers OpenAPI - GW라우팅 중 오류가 발생했습니다.
13523정성태1/12/20246000오류 유형: 889. Visual Studio - error : A project with that name is already opened in the solution.
13522정성태1/11/20246801닷넷: 2200. C# - HttpClient.PostAsJsonAsync 호출 시 "Transfer-Encoding: chunked" 대신 "Content-Length" 헤더 처리
13521정성태1/11/20247036닷넷: 2199. C# - 한국투자증권 KIS Developers OpenAPI의 WebSocket Ping, Pong 처리
13520정성태1/10/20246690오류 유형: 888. C# - Unable to resolve service for type 'Microsoft.Extensions.ObjectPool.ObjectPool`....' [1]
13519정성태1/10/20246155닷넷: 2198. C# - Reflection을 이용한 ClientWebSocket의 Ping 호출파일 다운로드1
13518정성태1/9/20246519닷넷: 2197. C# - ClientWebSocket의 Ping, Pong 처리
13517정성태1/8/20246276스크립트: 63. Python - 공개 패키지를 이용한 위성 이미지 생성 (pystac_client, odc.stac)
13516정성태1/7/20246082닷넷: 2196. IIS - AppPool의 "Disable Overlapped Recycle" 옵션의 부작용
1  2  3  4  5  6  7  8  9  10  11  12  [13]  14  15  ...