Monitor 잠금은 스레드를 기억하는 유형입니다. 그래서, lock을 보유한 스레드만이 해제를 할 수 있습니다. 가령, 다음과 같이 다른 스레드에서 lock을 해제하려고 하면,

internal class Program
{
    static object _obj = new object();

    static void Main(string[] args)
    {
        Monitor.Enter(_obj); // lock을 획득
        
        Thread t = new Thread(() =>
        {
            Monitor.Exit(_obj); // 다른 스레드에서 lock을 해제
        });

        t.Start();
        t.Join();
    }
}

이런 예외가 발생합니다.

Unhandled exception. System.Threading.SynchronizationLockException: Object synchronization method was called from an unsynchronized block of code.
   at System.Threading.Monitor.Exit(Object obj)
   at Program.<>c.<Main>b__1_0() 

문서에서는, 이를 가리켜 "thread affinity"가 있다고 합니다.

Monitor 잠금이 스레드를 기억한다는 것 외에 잠금의 횟수를 기억한다는 특징도 있습니다. 그러니까, 하나의 스레드에서 Enter를 2번 호출했다면, Exit도 2번 호출해야만 잠금이 풀립니다. 아래의 코드는 그에 대한 재현을 보여주는데요,

internal class Program
{
    static object _obj = new object();

    static void Main(string[] args)
    {
        Console.WriteLine("Lock++");
        Monitor.Enter(_obj);
        Console.WriteLine("Lock++");
        Monitor.Enter(_obj); // 2번 잠금

        Thread t = new Thread(() =>
        {
            Monitor.Enter(_obj); // 다른 스레드에서 lock을 얻으려고 시도
            Console.WriteLine("Thread 1");
            Monitor.Exit(_obj);
        });

        t.Start();

        Console.WriteLine($"{DateTime.Now} Lock--");
        Monitor.Exit(_obj); // 한 번 잠금을 해제
        Thread.Sleep(5000);
        Console.WriteLine($"{DateTime.Now} Lock--");
        Monitor.Exit(_obj); // 두 번 잠금을 해제 - 이 시점에 "Thread 1"이 출력됨

        t.Join();
    }
}

실행하면 화면에는 다음과 같은 결과가 나옵니다.

Lock++
Lock++
2024-07-26 오후 18:44:40 Lock--
2024-07-26 오후 18:44:45 Lock--  // 5초 후 2번째 잠금이 해제되고 나서야 "Thread 1"이 출력됨
Thread 1

결국, 위의 2가지 성격으로 볼 때 Monitor 잠금은 Mutex와 같은 성격(thread affinity, reentrancy)을 가지고 있습니다. 따라서 Monitor와 같은 lock이 필요한데 그것이 프로세스 경계를 넘어서도 유효해야 한다면 유형만 Mutex로 그대로 치환할 수 있습니다.

역시나 Mutex가 그랬던 것처럼,

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

Monitor 역시 비동기 환경에서는 동일한 제약이 있습니다. 일례로, (내부적으로 Monitor를 사용하는) lock 문 내에서 비동기 호출을 하면,

internal class Program
{
    static object _obj = new object();

    static async Task Main(string[] args)
    {
        lock (_obj)
        {
            // error CS1996: Cannot await in the body of a lock statement
            await Task.Delay(2000);
        }
    }
}

C# 컴파일러는 이것을 인지하고 오류를 발생시킵니다. 반면, 저 코드를 Monitor.Enter/Exit로 풀어내면 컴파일 오류는 발생하지 않지만,

internal class Program
{
    static object _obj = new object();

    static async Task Main(string[] args)
    {
        Monitor.Enter(_obj);

        await Task.Delay(2000);

        Monitor.Exit(_obj); // 실행 시 오류
    }
}

결국엔 Monitor.Exit 코드를 실행하는 스레드가 달라져 이런 오류가 발생합니다.

Unhandled exception. System.Threading.SynchronizationLockException: Object synchronization method was called from an unsynchronized block of code.
   at System.Threading.Monitor.Exit(Object obj)
   at Program.Main(String[] args) 
   at Program.<Main>(String[] args)

하지만, lock 대신 Monitor.Enter/Exit를 사용할 만한 경우가 있긴 합니다. 바로 SynchronizationContext를 사용해 비동기 호출 이후의 코드를 원래 스레드에서 실행하게 되는 경우입니다. 대표적인 예로, Windows Forms나 WPF 환경인데요, 따라서 Windows Forms에서는 다음과 같이 풀어서 Monitor를 이용한 동기화 개체를 쓸 수 있습니다.

public partial class Form1 : Form
{
    object _obj = new object();

    public Form1()
    {
        InitializeComponent();
    }

    private async void Form1_Load(object sender, EventArgs e)
    {
        bool lockTaken = false;
        try
        {
            Monitor.Enter(_obj, ref lockTaken);
            await Task.Delay(2000);
        }
        finally
        {
            if (lockTaken)
            {
                Monitor.Exit(_obj);
            }
        }
    }
}

재미있게도, 동일한 코드로 번역하는 lock 예약어 방식을 쓰면 컴파일 오류가 발생하고,

private async void Form1_Load(object sender, EventArgs e)
{
    lock (_obj) // 컴파일 오류: error CS1996: Cannot await in the body of a lock statement
    {
        await Task.Delay(2000);
    }
}

Monitor.Enter/Exit를 쓴다고 해도 SynchronizationContext를 사용하지 않도록 ConfigureAwait(false)을 추가하면,

private async void Form1_Load(object sender, EventArgs e)
{
    bool lockTaken = false;
    try
    {
        Monitor.Enter(_obj, ref lockTaken);
        await Task.Delay(2000).ConfigureAwait(false);
    }
    finally
    {
        if (lockTaken)
        {
            Monitor.Exit(_obj); // 실행 시 오류: System.Threading.SynchronizationLockException: 'Object synchronization method was called from an unsynchronized block of code.'
        }
    }
}

Monitor.Exit 코드를 스레드풀로부터 빌려온 스레드가 호출하므로 역시 실행 시 예외가 발생합니다.

만약 비동기 상황에서의 lock을 처리하고 싶다면, 해결책은 "C# - Mutex의 비동기 버전" 글에 쓴 내용과 동일합니다. 즉, Semaphore(Slim)을 사용하면 됩니다. 다음은 그에 대한 예제입니다.

namespace WinFormsApp1;

public partial class Form1 : Form
{
    SemaphoreSlim _sem = new SemaphoreSlim(1);

    public Form1()
    {
        InitializeComponent();
    }

    private async void Form1_Load(object sender, EventArgs e)
    {
        _sem.Wait(); // Main 스레드에서 lock 획득

        new Thread(() =>
        {
            System.Diagnostics.Trace.WriteLine($"[{DateTime.Now}] --------------------- Thread called");
            _sem.Wait(); // 사용자 스레드에서 lock 획득 시도
            try
            {
                System.Diagnostics.Trace.WriteLine($"[{DateTime.Now}] --------------------- got Semaphore");
                Thread.Sleep(2000);
            }
            finally
            {
                _sem.Release();
            }
        })
        { IsBackground = true }.Start();

        try
        {
            await Task.Delay(5000).ConfigureAwait(false); // 5초 후에,
        } finally
        {
            _sem.Release(); // 스레드풀의 스레드에서 lock 해제
        }
    }
}