C# - Mutex와 Semaphore/SemaphoreSlim 차이점
그러고 보니, 제 블로그에서 Mutex나 Semaphore에 대해 다룬 적이 거의 없었군요. ^^; 이참에 한번 정리해보겠습니다.
두 개 모두 동기화 개체지만, 사실 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
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]