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

비밀번호

댓글 작성자
 




... 121  122  123  124  125  126  127  [128]  129  130  131  132  133  134  135  ...
NoWriterDateCnt.TitleFile(s)
1856정성태2/15/201521257.NET Framework: 493. TypeRef 메타테이블에 등록되는 타입의 조건파일 다운로드1
1855정성태2/10/201520800개발 환경 구성: 256. WebDAV Redirector - Sysinternals 폴더 연결 시 "The network path was not found" 오류 해결 방법
1854정성태2/10/201521798Windows: 104. 폴더는 삭제할 수 없지만, 그 하위 폴더/파일은 생성/삭제/변경하는 보안 설정
1853정성태2/6/201552058웹: 29. 여신금융협회 웹 사이트의 "Netscape 6.0은 지원하지 않습니다." 오류 메시지 [5]
1852정성태2/5/201522484.NET Framework: 492. .NET CLR Memory 성능 카운터의 의미파일 다운로드1
1851정성태2/5/201523398VC++: 88. 하룻밤의 꿈 - 인텔 하스웰의 TSX Instruction 지원 [2]
1850정성태2/4/201544237Windows: 103. 작업 관리자에서의 "Commit size"가 가리키는 메모리의 의미 [4]
1849정성태2/4/201524189기타: 51. DropBox의 CPU 100% 현상 [1]파일 다운로드1
1848정성태2/4/201519425.NET Framework: 491. 닷넷 Generic 타입의 메타 데이터 토큰 값 알아내는 방법 [2]
1847정성태2/3/201522719기타: 50. C# - 윈도우에서 dropbox 동기화 폴더 경로 및 종료하는 방법
1846정성태2/2/201532014Windows: 102. 제어판의 프로그램 추가/삭제 항목을 수동으로 실행하고 싶다면? [1]
1845정성태1/26/201532896Windows: 101. 제어판의 "Windows 자격 증명 관리(Manage your credentials)"를 금지시키는 방법
1844정성태1/26/201530847오류 유형: 269. USB 메모리의 용량이 비정상적으로 보여진다면? [7]
1843정성태1/24/201521906VC++: 87. 무시할 수 없는 Visual C++ 런타임 함수 성능
1842정성태1/23/201544417개발 환경 구성: 255. 노트북 키보드에 없는 BREAK 키를 다른 키로 대체하는 방법
1841정성태1/21/201519391오류 유형: 268. Win32 핸들 관련 CLR4 보안 오류 사례
1840정성태1/8/201527612오류 유형: 267. Visual Studio - CodeLens 사용 시 CPU 100% 현상
1839정성태1/5/201520530디버깅 기술: 69. windbg 분석 사례 - cpu 100% 현상 (2)
1838정성태1/4/201540233기타: 49. 윈도우 내레이터(Narrator) 기능 끄는 방법(윈도우에 파란색의 굵은 테두리 선이 나타난다면?) [4]
1837정성태1/4/201526335디버깅 기술: 68. windbg 분석 사례 - 메모리 부족 [1]
1836정성태1/4/201526353디버깅 기술: 67. windbg - 덤프 파일과 handle 정보
1835정성태1/3/201526843개발 환경 구성: 254. SQL 서버 역시 SSL 3.0/TLS 1.0만을 지원하는 듯!
1834정성태1/3/201551475개발 환경 구성: 253. TLS 1.2를 적용한 IIS 웹 사이트 구성
1833정성태1/3/201527543.NET Framework: 490. System.Data.SqlClient는 SSL 3.0/TLS 1.0만 지원하는 듯! [3]
1832정성태1/2/201520645오류 유형: 266. Azure에 응용 프로그램 게시 중 로그인 오류
1831정성태1/1/201528525디버깅 기술: 66. windbg 분석 사례 - cpu 100% 현상 (1) [1]
... 121  122  123  124  125  126  127  [128]  129  130  131  132  133  134  135  ...