Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
(연관된 글이 1개 있습니다.)

C# - lock (this), lock (typeof(...))를 사용하면 안 되는 이유

마침 질문도 있고,

스레드 lock 키워드 관련 질문드립니다
; https://www.sysnet.pe.kr/3/0/5341

한 번도 관련 글을 직접적으로 소개한 적이 없어서 이참에 다뤄보겠습니다. ^^ 사실 이번 글은 이미 다음의 자료에서 잘 설명하고 있습니다.

Reliability Best Practices
; https://learn.microsoft.com/en-us/dotnet/framework/performance/reliability-best-practices




우선 질문과 관계된 항목을 먼저 풀어보겠습니다.

A note about lock(this)
; https://learn.microsoft.com/en-us/dotnet/framework/performance/reliability-best-practices#a-note-about-lockthis

예를 들어 다음과 같은 코드가 있다고 했을 때,

// 첨부 파일의 ConsoleApp1 프로젝트
class MyTest
{
    public void Do()
    {
        lock (this)
        {
            // ...
        }
    }
}

여기서 사용한 this는 그 객체 자신의 참조를 가리킨다는 점이 문제가 되는데, 왜냐하면 해당 타입의 인스턴스를 생성했을 때 그 인스턴스로 외부에서 lock을 걸 수 있기 때문입니다.

MyTest tinst = new MyTest();
lock (tinst) // 내부의 lock (this)와 동일한 잠금 획득 시도
{
    // ...
}

이를 바탕으로 간단하게 재현 코드를 만들어 볼까요?

class Program
{
    static void Main(string[] args)
    {
        MyTest inst = new MyTest();

        Thread t = new Thread((objInst) =>
        {
            inst.Do();
        });

        t.Start(inst);

        Thread.Sleep(1000);

        lock (inst)
        {
            Console.WriteLine("This code");
        }
    }
}

class MyTest
{
    public void Do()
    {
        lock (this)
        {
            string txt = Console.ReadLine();
            Console.WriteLine(txt);
        }
    }
}

위의 코드는 (MyTest 타입이 3rd-party 라이브러리에 정의되었다고 가정하고) 개발자가 왜 "This code" 문자열이 화면에 출력되지 않는지 이해할 수 없게 만들어 버립니다. (만약 초보 개발자라면 정말 신기한 현상이라며 어쩌면 닷넷 프레임워크의 버그라고까지 생각할 수도 있을 것입니다.)

결국, 내부의 잠금에 관계된 lock 인스턴스를 외부에 제공한 것이 문제가 된 것으로, 마치 다음과 같은 식으로 프로그램한 것과 동일한 효력을 가집니다.

class MyTest
{
    public object LockInstance = new object();

    public void Do()
    {
        lock (LockInstance)
        {
            // ...
        }
    }
}

아마 lock (this)라고 코딩했을 때 Visual Studio 편집기가 자동으로 저렇게 public object로 확장해 코드를 변경해 준다면, 누구도 public 접근자를 그대로 두는 것을 원치 않았을 것입니다.




위의 lock (this) 문제점을 이해했으면 이제 다음의 글도 동일한 맥락으로 파악할 수 있습니다.

Avoid lock(typeof(MyType))
; https://learn.microsoft.com/en-us/dotnet/framework/performance/reliability-best-practices#avoid-locktypeofmytype

lock (this)가 잠금 객체를 public하게 접근할 수 있게 만들었던 것이 문제였던 것처럼, lock (typeof(...)) 역시 해당 타입을 접근할 수 있다면 모든 곳에서 사용할 수 있기 때문에 동일한 문제가 발생합니다. 이외에도 lock (typeof(...))에는 한 가지 더 중요한 문제점이 있습니다.

Private and public Type objects in shared assemblies with only one copy of the code shared across all application domains also present problems.


"shared assemblies"는 "SharedDomain"에 로드되는 어셈블리들로 다음의 글에 설명한,

.NET - 눈으로 확인하는 SharedDomain의 동작 방식
; https://www.sysnet.pe.kr/2/0/10948

(AppDomain의 동작 방식에 따라 다르지만,) 기본 값인 SingleDomain의 경우에는 mscorlib.dll만 shared이므로 그 안에 있는 타입은 AppDomain 전체에 걸쳐 lock 잠금이 발생하게 됩니다. 예를 들어 아래는 재현 코드입니다.

// 첨부 파일의 ConsoleApp2 프로젝트

class Program
{
    static void Main(string[] args)
    {
        Thread t = new Thread(() =>
        {
            AppDomain appDomain = AppDomain.CreateDomain("testDomain");
            appDomain.DoCallBack(new CrossAppDomainDelegate(() =>
            {
                lock (typeof(Console))
                {
                    string txt = Console.ReadLine();
                    Console.WriteLine(txt);
                }
            }));
        });

        t.Start();
        Thread.Sleep(1000);

        lock (typeof(Console))
        {
            Console.WriteLine("This code");
        }

    }
}

(shared assembly인) mscorlib.dll의 Console 타입에 대해 lock을 걸었으므로 상이한 AppDomain에서 lock을 걸었는데도 "This code" 텍스트가 출력되지 않는 것을 확인할 수 있습니다. 반면, 위의 "lock (typeof(Console))"을 "lock (typeof(Program))"으로 변경하면 이번에는 "This code" 출력이 발생합니다. 왜냐하면, SingleDomain의 경우 위의 코드를 구현한 어셈블리는 공유되지 않으므로 typeof(Program)이 해당 AppDomain 내에서 고유한 인스턴스로 나오기 때문입니다.

당연히 이런 상황은 사용하는 측에 의존하게 됩니다. 만약 Main 메서드에 다음과 같이 MultiDomain 속성을 주면,

class Program
{
    [LoaderOptimization(LoaderOptimization.MultiDomain)]
    static void Main(string[] args)
    {
        // ...
    }
}

Program 타입을 정의한 어셈블리도 shared가 되므로, 이번에는 "lock (typeof(Program))"에서도 "This code"가 출력되지 않습니다. 그러니까, 아무리 의도해서 typeof(...)를 사용했다고 해도 그것을 사용하는 측에서 AppDomain을 어떤 식으로 운영하느냐에 따라 다른 결과를 가져오므로 typeof(...)를 lock에 사용하는 것은 피해야 합니다.

참고로, AppDomain은 .NET Core 환경에서는 개발자가 임의로 만들 수 없기 때문에 저런 식의 문제는 이제 더 이상 볼 일이 없을 것입니다. (적어도 .NET 5.0 Preview 4까지는 AppDomain.CreateDomain을 지원하지 않습니다.)




프로세스 전체에 걸쳐서 유일한 인스턴스로 다뤄지는 것은 shared assemblies에서만 발생하는 것은 아닙니다. 가령 다음과 같이 문자열을 직접적으로 사용하는 경우에도, 프로세스에 고유하게 interning시킨 문자열 풀의 인스턴스가 사용되기 때문에,

// 첨부 파일의 ConsoleApp3 프로젝트
static void Main(string[] args)
{
    Thread t = new Thread(() =>
    {
        AppDomain appDomain = AppDomain.CreateDomain("testDomain");

        appDomain.DoCallBack(new CrossAppDomainDelegate(() =>
        {
            lock ("mytest")
            {
                string txt = Console.ReadLine();
                Console.WriteLine(txt);
            }
        }));
    });

    t.Start();
    Thread.Sleep(1000);

    lock ("mytest")
    {
        Console.WriteLine("This code");
    }
}

"lock (typeof(Console))"과 동일한 문제가 발생합니다. 사실 저런 식으로 lock을 쓰는 개발자는 거의 없을 것이므로 문제가 될 여지가 없겠지만 그냥 이해 차원에서 봐두면 되겠습니다.




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

[연관 글]






[최초 등록일: ]
[최종 수정일: 2/15/2024]

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

비밀번호

댓글 작성자
 




... 31  32  33  [34]  35  36  37  38  39  40  41  42  43  44  45  ...
NoWriterDateCnt.TitleFile(s)
12788정성태8/17/20217921.NET Framework: 1093. C# - 인터페이스의 메서드가 다형성을 제공할까요? (virtual일까요?)파일 다운로드1
12787정성태8/17/20218139.NET Framework: 1092. (책 내용 수정) "4.5.1.4 인터페이스"의 "인터페이스와 다형성"
12786정성태8/16/20219708.NET Framework: 1091. C# - Python range 함수 구현 (2) INumber<T>를 이용한 개선 [1]파일 다운로드1
12785정성태8/16/20217962.NET Framework: 1090. .NET 6 Preview 7에 추가된 숫자 형식에 대한 제네릭 연산 지원 [1]파일 다운로드1
12784정성태8/15/20217375오류 유형: 757. 구글 메일 - 아웃룩에서 메일 전송 시 Sending' reported error (0x800CCC0F, 0x800CCC92)
12783정성태8/15/20216895.NET Framework: 1089. C# - Indexer에 Range 및 람다 식을 이용한 필터 구현 [1]파일 다운로드1
12782정성태8/14/20216691오류 유형: 756. 파이썬 - 윈도우 환경에서 pytagcloud의 한글 출력 방법
12781정성태8/14/20218880오류 유형: 755. 파이썬 - konlpy 사용 시 JVM과 jpype1 관련 오류
12780정성태8/13/20217240.NET Framework: 1088. C# - 버스 노선 및 위치 정보 조회 API 사용을 위한 기초 라이브러리 [2]
12779정성태8/13/20219120개발 환경 구성: 596. 공공 데이터 포털에서 버스 노선 및 위치 정보 조회 API 사용법
12778정성태8/12/20216350오류 유형: 755. PyCharm - "Manage Repositories"의 목록이 나오지 않는 문제
12777정성태8/12/20217948오류 유형: 754. Visual Studio - Input or output cannot be redirected because the specified file is invalid.
12776정성태8/12/20217311오류 유형: 753. gunicorn과 uwsgi 함께 사용 시 ERR_CONNECTION_REFUSED
12775정성태8/12/202118177스크립트: 22. 파이썬 - 윈도우 환경에서 개발한 Django 앱을 WSL 환경의 gunicorn을 이용해 실행
12774정성태8/11/20218928.NET Framework: 1087. C# - Collection 개체의 다중 스레드 접근 시 "Operations that change non-concurrent collections must have exclusive access" 예외 발생
12773정성태8/11/20218092개발 환경 구성: 595. PyCharm - WSL과 연동해 Django App을 윈도우에서 리눅스 대상으로 개발
12772정성태8/11/20219580스크립트: 21. 파이썬 - 윈도우 환경에서 개발한 Django 앱을 WSL 환경의 uwsgi를 이용해 실행 [1]
12771정성태8/11/20217995Windows: 196. "Microsoft Windows Subsystem for Linux Background Host" / "Vmmem"을 종료하는 방법
12770정성태8/11/20218722.NET Framework: 1086. C# - Windows Forms 응용 프로그램의 자식 컨트롤 부하파일 다운로드1
12769정성태8/11/20216630오류 유형: 752. Python - ImportError: No module named pip._internal.cli.main 두 번째 이야기
12768정성태8/10/20217714.NET Framework: 1085. .NET 6에 포함된 신규 BCL API [1]파일 다운로드1
12767정성태8/10/20218781오류 유형: 752. Python - ImportError: No module named pip._internal.cli.main
12766정성태8/9/20217231Java: 32. closing inbound before receiving peer's close_notify
12765정성태8/9/20216585Java: 31. Cannot load JDBC driver class 'org.mysql.jdbc.Driver'
12764정성태8/9/202145036Java: 30. XML document from ServletContext resource [/WEB-INF/applicationContext.xml] is invalid
12763정성태8/9/20218063Java: 29. java.lang.NullPointerException - com.mysql.jdbc.ConnectionImpl.getServerCharset
... 31  32  33  [34]  35  36  37  38  39  40  41  42  43  44  45  ...