Microsoft MVP성태의 닷넷 이야기
닷넷: 2285. C# - async 메서드에서의 System.Threading.Lock 잠금 처리 [링크 복사], [링크+제목 복사],
조회: 8296
글쓴 사람
정성태 (seongtaejeong at gmail.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# - async 메서드에서의 System.Threading.Lock 잠금 처리

.NET 9부터 새롭게 도입한 System.Threading.Lock 타입 역시 Monitor 및 Mutex와 그대로 치환이 됩니다. 즉, lock을 소유한 스레드를 알고 있으며 재진입에 따른 잠금 횟수를 관리합니다.

따라서, 다음의 코드는,

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

    static void Main(string[] args)
    {
        _obj.Enter();
        
        Thread t = new Thread(() =>
        {
            _obj.Exit(); // 실행 시: System.Threading.SynchronizationLockException: 'The calling thread does not hold the lock.'
        });

        t.Start();

        t.Join();
    }
}

실행 시점에 Exit를 호출하는 코드에서 예외가 발생합니다. 마찬가지로 다음의 코드도,

internal class Program
{
    static Lock _obj = new();
    static void Main(string[] args)
    {
        _obj.Enter();
        _obj.Enter(); // 2번 잠금

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

        t.Start();

        _obj.Exit(); // 한 번 잠금을 해제
        Thread.Sleep(5000);
        _obj.Exit(); // 두 번 잠금을 해제 - 이 시점에 "Thread 1"이 출력됨

        t.Join();
    }
}

Main 스레드에서 _obj.Exit를 2번 호출한 시점에야 lock이 풀려 Thread의 내부 코드가 실행됩니다.




비동기 문맥에서도 역시 Monitor와 동일한 동작을 보이는데, lock 예약어를 이용한 코드는 아예 컴파일 단계에서 오류를 발생시키고,

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

    static async Task Main(string[] args)
    {
        lock (_obj)
        {
            await Task.Delay(2000); // error CS4007: Instance of type 'System.Threading.Lock.Scope' cannot be preserved across 'await' or 'yield' boundary.
        }
    }
}

Enter/Exit로 풀어내면 컴파일 오류는 피할 수 있지만, Exit 시점에 여전히 예외는 발생합니다.

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

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

        await Task.Delay(2000);

        // 컴파일은 되지만,
        _obj.Exit(); // 실행 시: System.Threading.SynchronizationLockException: 'The calling thread does not hold the lock.'
    }
}

SynchronizationContext 환경을 제공하는 Windows Forms/WPF까지 Enter/Exit로 풀어내 사용하는 것은 Monitor와 일치합니다.

Lock _obj = new();

private async void Form1_Load(object sender, EventArgs e)
{
    _obj.Enter();

    try
    {
        await Task.Delay(2000);
    }
    finally
    {
        _obj.Exit(); // SynchronizationContext에 따라 Enter를 호출한 스레드에서 Exit를 호출하므로 동기화 성공
    }
}

유의해야 할 점은, (lock 예약어가 내부적으로 사용하는) Scope를 사용한 경우에는 컴파일 오류가 발생한다는 점입니다.

var scope = _obj.EnterScope();

try
{
    await Task.Delay(2000);
}
finally
{
    scope.Dispose(); // 컴파일 오류: error CS4007: Instance of type 'System.Threading.Lock.Scope' cannot be preserved across 'await' or 'yield' boundary.
}

따라서 SynchronizationContext가 있음을 알고 의도적으로 System.Threading.Lock을 사용하는 경우라면 Enter/Exit를 사용해야 합니다. (참고로, scope.Dispose 코드를 주석 처리하면 컴파일은 되지만, 당연히 lock은 해제되지 않아 결국엔 문제가 발생합니다.)

정리하면, System.Threading.Lock 역시 (스레드가 바뀌는) 비동기 문맥에서는 사용할 수 없고, 그런 경우를 원한다면 Semaphore(Slim)을 사용해야 합니다.

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




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

[연관 글]






[최초 등록일: ]
[최종 수정일: 8/6/2024]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 




... 166  167  168  169  170  171  172  173  174  175  176  177  178  179  [180]  ...
NoWriterDateCnt.TitleFile(s)
483정성태3/17/200740748오류 유형: 30. x64 환경: .NET + COM 프로젝트 실행 시 오류 - 80040154 [2]
482정성태3/17/200730260Team Foundation Server: 17. 팀 프로젝트 접속 및 사용
481정성태3/17/200724185Team Foundation Server: 16. 팀 프로젝트 읽기 전용 사용자 등록
480정성태3/14/200722288.NET Framework: 86. GC(Garbage Collector)의 변화
479정성태3/14/200726327개발 환경 구성: 25. D820 - ReadyBoost 구동
478정성태3/14/200725651개발 환경 구성: 24. D820 고주파음 문제
477정성태3/14/200734966개발 환경 구성: 23. 비스타 x64 버전에서 서명되지 않은 드라이버 사용 [4]
476정성태3/9/200730353개발 환경 구성: 22. D820 노트북 - 설치 및 BitLocker 구성 [1]
475정성태3/6/200724710.NET Framework: 85. 공용 프로퍼티 자동 생성
474정성태3/5/200722940.NET Framework: 84. Lambda 표현식 응용 사례 [1]
473정성태3/4/200730037디버깅 기술: 14. TFS 오류 추적(TF53010, TF14105)
472정성태3/3/200729136디버깅 기술: 13. 예외 발생 시 Minidump 생성 - WinDBG [3]파일 다운로드1
471정성태3/1/200718366디버깅 기술: 12. Managed Method에 Break Point 걸기
469정성태2/28/200729867디버깅 기술: 11. (Managed) Main Method에 Break Point 걸기 [3]파일 다운로드1
470정성태3/1/200721230    답변글 디버깅 기술: 11.1. (Managed) Main Method에 Break Point 걸기 - 내용 보강
468정성태2/25/200731111COM 개체 관련: 20. 탭 브라우저의 윈도우 핸들 구하기 [3]
466정성태2/22/200722820Windows: 23. 롱혼 서버 코어 버전 [2]
465정성태2/21/200721774오류 유형: 29. TFS 관련 스케줄 작업 실패
464정성태2/25/200722969오류 유형: 28. TF10217, TF53010, TF14105 오류
463정성태2/21/200715997Team Foundation Server: 15. 포탈 사이트의 보고서 주소를 도메인 명으로 적용
462정성태2/13/200743284.NET Framework: 83. 라이브러리에 다국어 리소스 추가 방법 [4]파일 다운로드1
461정성태2/13/200720977오류 유형: 27. DLinq 예제 오류 : error: 26 - Error Locating Server/Instance Specified
460정성태2/13/200721190.NET Framework: 82. Orcas 1월 CTP에서 Linq 소스 컴파일 방법
459정성태2/17/200725194오류 유형: 26. "Automatic Updates" 서비스 CPU 100% 점유 현상 - 두 번째 이야기 [3]
458정성태2/12/200721663.NET Framework: 81. LINQ 개발 환경 설정 [1]
457정성태2/8/200726145.NET Framework: 80. LINQ 관련 용어 정리 및 리소스 소개 [2]
... 166  167  168  169  170  171  172  173  174  175  176  177  178  179  [180]  ...