Microsoft MVP성태의 닷넷 이야기
닷넷: 2284. C# - async 메서드에서의 lock/Monitor.Enter/Exit 잠금 처리 [링크 복사], [링크+제목 복사],
조회: 3686
글쓴 사람
정성태 (seongtaejeong at gmail.com)
홈페이지
첨부 파일
(연관된 글이 2개 있습니다.)
(시리즈 글이 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# - async 메서드에서의 lock/Monitor.Enter/Exit 잠금 처리

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 해제
        }
    }
}

개인적으로 Semaphore를 싫어하지만, 저런 경우는 어쩔 수 없습니다. ^^

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




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

[연관 글]






[최초 등록일: ]
[최종 수정일: 8/6/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)
13761정성태10/11/2024995오류 유형: 927. WSL / Ubuntu - /usr/include/linux/types.h:5:10: fatal error: 'asm/types.h' file not found
13760정성태10/11/2024986Linux: 82. Ubuntu - clang 최신(stable) 버전 설치
13759정성태10/10/20241921C/C++: 177. C++ - 자유 함수(free function) 및 주소 지정 가능한 함수(addressable function) [6]
13758정성태10/8/20241413오류 유형: 926. dotnet tools를 sudo로 실행하는 경우 command not found
13757정성태10/8/20241582닷넷: 2306. Linux - dotnet tool의 설치 디렉터리가 PATH 환경변수에 자동 등록이 되는 이유
13756정성태10/8/20241350오류 유형: 925. ssh로 docker 접근을 할 때 "... malformed HTTP status code ..." 오류 발생
13755정성태10/7/20241738닷넷: 2305. C# 13 - (9) 메서드 바인딩의 우선순위를 지정하는 OverloadResolutionPriority 특성 도입 (Overload resolution priority)파일 다운로드1
13754정성태10/4/20241389닷넷: 2304. C# 13 - (8) 부분 메서드 정의를 속성 및 인덱서에도 확대파일 다운로드1
13753정성태10/4/20241881Linux: 81. Linux - PATH 환경변수의 적용 규칙
13752정성태10/2/20242232닷넷: 2303. C# 13 - (7) ref struct의 interface 상속 및 제네릭 제약으로 사용 가능파일 다운로드1
13751정성태10/2/20241830C/C++: 176. C/C++ - ARM64로 포팅할 때 유의할 점
13750정성태10/1/20241429C/C++: 175. C++ - WinMain/wWinMain 호출 전의 CRT 초기화 단계
13749정성태9/30/20241697닷넷: 2302. C# - ssh-keygen으로 생성한 Private Key와 Public Key 연동파일 다운로드1
13748정성태9/29/20241684닷넷: 2301. C# - BigInteger 타입이 byte 배열로 직렬화하는 방식
13747정성태9/28/20241531닷넷: 2300. C# - OpenSSH의 공개키 파일에 대한 "BEGIN OPENSSH PUBLIC KEY" / "END OPENSSH PUBLIC KEY" PEM 포맷파일 다운로드1
13746정성태9/28/20241581오류 유형: 924. Python - LocalProtocolError("Illegal header value ...")
13745정성태9/28/20241469Linux: 80. 리눅스 - 실행 중인 프로세스 내부의 환경변수 설정을 구하는 방법 (lldb)
13744정성태9/27/20242241닷넷: 2299. C# - Windows Hello 사용자 인증 다이얼로그 표시하기파일 다운로드1
13743정성태9/26/20242109닷넷: 2298. C# - Console 프로젝트에서의 await 대상으로 Main 스레드 활용하는 방법 [1]
13742정성태9/26/20242661닷넷: 2297. C# - ssh-keygen으로 생성한 ecdsa 유형의 Public Key 파일 해석 [1]파일 다운로드1
13741정성태9/25/20241903디버깅 기술: 202. windbg - ASP.NET MVC Web Application (.NET Framework) 응용 프로그램의 덤프 분석 시 요령
13740정성태9/24/20241972기타: 86. RSA 공개키 등의 modulus 값에 0x00 선행 바이트가 있는 이유(ASN.1 인코딩)
13739정성태9/24/20241789닷넷: 2297. C# - ssh-keygen으로 생성한 Public Key 파일 해석과 fingerprint 값(md5, sha256) 생성 [1]파일 다운로드1
13738정성태9/22/20241632C/C++: 174. C/C++ - 윈도우 운영체제에서의 file descriptor, FILE*파일 다운로드1
13737정성태9/21/20242104개발 환경 구성: 727. Visual C++ - 리눅스 프로젝트를 위한 빌드 서버의 msbuild 구성
13736정성태9/20/20241838오류 유형: 923. Visual Studio Code - Could not establish connection to "...": Port forwarding is disabled.
1  2  [3]  4  5  6  7  8  9  10  11  12  13  14  15  ...