Microsoft MVP성태의 닷넷 이야기
.NET Framework: 274. ReaderWriterLockSlim 은 언제 쓰는 걸까요? [링크 복사], [링크+제목 복사]
조회: 12547
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일

ReaderWriterLockSlim 은 언제 쓰는 걸까요?


지난 번 글에서 닷넷에서의 동기화 처리 방식에 대해서 설명을 했었지요.

.NET 참조 개체 인스턴스의 SyncBlock 을 확인하는 방법
; https://www.sysnet.pe.kr/2/0/1175

일반적으로 C# 에서는 다음과 같이 동기화를 합니다.

object lockInstance = new object();

lock (lockInstance)
{
   ... [공유자원 접근] ...
}

lock (...) 메커니즘은 배타적인 잠금(exclusive lock)을 걸어서 해당 자원을 보호하게 됩니다. 그런데, 가끔은 해당 자원에 대해서 거의 모든 쓰레드들이 '읽기'만 하고 가끔씩 '소수의 쓰레드'만 '쓰기' 작업을 한다고 했을 때 ex-lock 은 왠지 아깝지 않은가 하는 생각이 들게 됩니다.

사실, lock 이 필요한 이유는 상태를 변경시키는 '쓰기' 때문에 발생하는 것이지, '읽기' 만 발생하는 상황이라면 굳이 lock 이 필요하지는 않습니다.

따라서 성능을 고려한다면, '읽기' 작업을 하는 쓰레드들 사이에서는 서로 방해를 하지 않고 있다가 '쓰기' 작업과의 연동에서만 '배타적 잠금'을 하는 것이 바람직합니다. 이런 경우가 바로 공유 잠금(shared lock)이라고 불리는 유형입니다.

어디... sh-lock 이 ex-lock 에 비해서 얼마나 성능이 향상되는지 한번 테스트를 해볼까요?

우선, 간단하게 카운트 루프를 도는 프로그램을 lock 으로 보호해 보겠습니다.

void lockThread(object state)
{
    int counterIndex = (int)state;

    while (threadStop == false)
    {
        lock (lockCount)
        {
            counts[counterIndex]++;
        }
    }
}

위와 같은 역할을 하는 쓰레드를 5개 만들어서 실행하면,

for (int i = 0; i < count; i++)
{
    Thread newThread = new Thread(lockThread);
    newThread.IsBackground = true;
    newThread.Start(i);
}

counts[0...4] 배열의 카운트 값들이 쓰레드 내의 while 루프를 돌 때 마다 증가할 것입니다. 시간을 재서 초당 증가하는 횟수를 살펴 보니 다음과 같이 나옵니다.

11904819.7152496 
11949052.7475766 
11931037.5872447 
11933239.6103584 
11881933.1463757 

==> 초당 약 12,000,000 번의 실행

그렇다면, 이제 쓰레드 함수에 ReaderWriterLockSlim 을 사용해서 공유 잠금을 해보겠습니다.

Slim Reader/Writer (SRW) Locks 
; http://msdn.microsoft.com/en-us/library/windows/desktop/aa904937(v=vs.85).aspx

ReaderWriterLockSlim cacheLock = new ReaderWriterLockSlim();

void readerThread(object state)
{
    int countIndex = (int)state;
            
    while (threadStop == false)
    {
        cacheLock.EnterReadLock();

        try
        {
            counts[countIndex]++;
        }
        finally
        {
            cacheLock.ExitReadLock();
        }
    }
}

void writerThread(object state)
{
    int countIndex = (int)state;

    while (threadStop == false)
    {
        cacheLock.EnterWriteLock();

        try
        {
            counts[countIndex]++;
        }
        finally
        {
            cacheLock.ExitWriteLock();
        }
    }
}

5개의 쓰레드 생성 시에, 첫번째 쓰레드에 대해서만 writerThread를 할당하고 나머지는 readerThread로 할당해 주었습니다.

for (int i = 0; i < count; i++)
{
    Thread newThread;
    
    if (i == 0)
    {
        newThread = new Thread(writerThread);
    }
    else
    {
        newThread = new Thread(readerThread);
    }

    newThread.IsBackground = true;
    newThread.Start(i);
}

자... 기대되는 군요. ^^ 이렇게 하고 실행하면 ex-lock 에 비해서 얼마나 성능 향상이 있을까요?

5439175.07101596 
5398816.34136504 
5390411.53317197 
5366829.75513943 
5351321.89442379 
5344019.70797552 
5334268.38922098 

==> 초당 약 5,500,000 번의 실행

오호~~~ 예상 외인가요? 무조건 잠금을 하는 ex-lock 이 12,000,000 번의 성능을 보였던 것에 비하면 절반도 안되는 수치를 기록하고 있습니다. 혹시... 테스트를 뭔가 잘못한 걸까요?

아닙니다. 테스트는 정확하게 했습니다. 위와 같은 상황에서는 가벼운 ex-lock 이 더 좋은 성능을 보일 수 밖에 없습니다.




그렇다면, lock 을 점유하는 시간이 다소 길어지면 어떤 현상이 발생할까요? 이를 위해 lock 점유를 흉내내기 위해 다음과 같이 1ms 에 해당하는 Thread.Sleep 시간을 쓰레드에 추가해 봤습니다.

void lockThread(object state)
{
    int counterIndex = (int)state;

    while (threadStop == false)
    {
        lock (lockCount)
        {
            counts[counterIndex]++;
            Thread.Sleep(1);
        }
    }
}

겨우 1ms 의 지연시간을 추가한 것 뿐인데, 초당 루프 증가 수는 다음과 같이 뚝 떨어졌습니다.

998.700954608068 
998.745307936315 
998.820608186942 
998.825143635559 
998.893010223893 

==> 초당 약 1,000 번의 실행

그럼 sh-lock 의 경우에는 어떨까요? 이번엔 정말 기대되는 군요. ^^ 역시 동일하게 1ms 의 지연 시간을 부여하고,

void readerThread(object state)
{
    int countIndex = (int)state;
            
    while (threadStop == false)
    {
        cacheLock.EnterReadLock();

        try
        {
            counts[countIndex]++;
            Thread.Sleep(1);
        }
        finally
        {
            cacheLock.ExitReadLock();
        }
    }
}

void writerThread(object state)
{
    int countIndex = (int)state;

    while (threadStop == false)
    {
        cacheLock.EnterWriteLock();

        try
        {
            counts[countIndex]++;
            Thread.Sleep(1);
        }
        finally
        {
            cacheLock.ExitWriteLock();
        }
    }
}

실행해 보면, 다음과 같은 결과를 얻을 수 있습니다.

1957.41883217647 
1900.581814786 
1912.05442748045 
1890.14059164164 
1908.65293256279 

==> 초당 약 1,900 번의 실행

상황이 역전되었군요. 기대했던 데로 이번엔 ex-lock 의 초당 약 1,000 번도 안되는 성능에 비하면 2배 정도의 향상된 수치를 보여주고 있습니다.




이 쯤 되면, 이번 글의 제목에 썼던 내용에 대해서 어느 정도 답을 하실 수 있을 것입니다.

ReaderWriterLockSlim 클래스는, 다중 읽기/소수 쓰기의 상황에서 보호되어야 할 자원이 있는 경우에 사용할 수 있는데, 그 효과를 발휘하려면 잠금 구간 사이의 체류 시간이 있어야 합니다.

예를 들어, 다중 쓰레드로부터 보호해야 하는 영역에 변수 1~2개 정도 두고 하는 거라면 Interlocked.Increment / Interlocked.Decrement 과 같은 것을 사용하거나 아예 가벼운 lock (...) 구문을 사용하시는 것이 성능을 위해 더욱 현명한 선택입니다.

허긴... 이렇게 머리로는 알고 있어도, ^^ 대부분의 성능 관련한 것들이 직접 측정을 하지 않으면 정확한 판단을 내릴 수 없는 경우가 많다는 것이... 문제라면 문제겠지요. ^^

(첨부된 파일은 위의 코드를 포함한 예제 프로젝트입니다.)




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

[연관 글]





[최초 등록일: ]
[최종 수정일: 11/22/2011 ]

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

비밀번호

댓글 쓴 사람
 



2011-11-22 11시08분
짧은 생각으로 무조건 ReaderWriterLockSlim 클래스가 성능이 더 우월할 것이다라는 생각을 실험결과로 깨주셨군요. ㅎㅎ 감사합니다.
도움 많이 되었습니다.
스포너
2011-11-23 12시56분
[아파야낫는다] CPU점유율이 100%와 0%가 나오네요
[손님]
2020-09-12 12시33분
[질문있습니다] ReaderThread 와 WriterThread를 구분해서 예시를 들어주셨는데 두가지 모두 counts[countIndex]++;로 값을 Write하고있네요. 혹시 오타이신건지 아니면 ReadLock WriteLock 둘다 쓰기도 가능한 방식인건지 궁금합니다.
그리고 WriteLock을 취득한 상태에서 Read를 하면 안되는건가요?
[손님]
2020-09-12 01시00분
본문을 보시면, 사실 lock을 했지만 그 안의 counts[counterIndex]는 각각의 스레드만 고유하게 접근하기 때문에 동기화 대상은 아닙니다. 그냥 내부 코드에서의 실행 횟수를 체크하기 위해 쓴 것이므로 그것을 위해 lock이 하는 일은 없습니다.

그래서 답변을 드리면,

1) ReadLock을 썼다고 해서 내부에서 어떤 값에 쓰기를 할 수 없는 것은 아닙니다. 단지, 그것이 다른 스레드에서 동시에 쓰기를 하는 대상, 즉 동기화 대상이라면 쓰기를 해서는 안 됩니다.

2) WriteLock 내에서는 동기화 대상에 대해 당연히 Read/Write 모두 가능합니다.
정성태

[1]  2  3  4  5  6  7  8  9  10  11  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
12379정성태10/21/202014.NET Framework: 955. .NET 메서드의 Signature 바이트 코드 분석파일 다운로드2
12378정성태10/20/2020111.NET Framework: 954. C# - x86/x64 환경에 따라 달라지는 P/Invoke 함수의 export 이름파일 다운로드1
12377정성태10/15/2020113디버깅 기술: 172. windbg - 파일 열기 시점에 bp를 걸어 파일명 알아내는 방법(Managed/Unmanaged)
12376정성태10/15/202045오류 유형: 669. windbg - sos의 name2ee 명령어 실행 시 "Failed to request module list." 오류
12375정성태10/15/2020150Windows: 177. 윈도우 탐색기에서 띄우는 cmd.exe 창의 디렉터리 구분 문자가 'Yen(&#0165;)' 기호로 나오는 경우 [1]
12374정성태10/14/2020131.NET Framework: 953. C# 9.0 - (6) Function pointers파일 다운로드2
12373정성태10/14/202069.NET Framework: 952. OpCodes.Box와 관련해 IL 형식으로 직접 코딩 시 유의할 점
12372정성태10/14/2020138.NET Framework: 951. C# 9.0 - (5) Attributes on local functions파일 다운로드1
12371정성태10/13/202052개발 환경 구성: 519. Visual Studio의 Ctrl+Shift+U (Edit.MakeUppercase) 단축키가 동작하지 않는 경우
12370정성태10/13/202053Linux: 33. Linux - nmcli를 이용한 고정 IP 설정
12369정성태10/21/2020814Windows: 176. Raymond Chen이 한글날에 밝히는 윈도우의 한글 자모 분리 현상 [1]
12368정성태10/12/202049오류 유형: 668. VSIX 확장 빌드 - The "GetDeploymentPathFromVsixManifest" task failed unexpectedly.
12367정성태10/12/202049오류 유형: 667. Ubuntu - Temporary failure resolving 'kr.archive.ubuntu.com'
12366정성태10/13/2020129.NET Framework: 950. C# 9.0 - (4) Native ints파일 다운로드1
12365정성태10/12/2020122.NET Framework: 949. C# 9.0 - (3) Lambda discard parameters파일 다운로드1
12364정성태10/11/2020159.NET Framework: 948. C# 9.0 - (2) Skip locals init파일 다운로드1
12363정성태10/11/2020173.NET Framework: 947. C# 9.0 - (1) Target-typed new파일 다운로드1
12362정성태10/11/2020155VS.NET IDE: 151. Visual Studio 2019에 .NET 5 rc/preview 적용하는 방법
12361정성태10/19/2020228.NET Framework: 946. C# 9.0을 위한 개발 환경 구성
12360정성태10/8/202067오류 유형: 666. The type or namespace name '...' does not exist in the namespace 'Microsoft.VisualStudio.TestTools' (are you missing an assembly reference?)
12359정성태10/7/202061오류 유형: 665. Windows - 재부팅 후 iSCSI 연결이 끊기는 문제
12358정성태10/7/202048오류 유형: 664. Web Deploy 설치 시 "A newer version of Microsoft Web Deploy 3.6 was found on this machine." 오류
12357정성태10/7/202049오류 유형: 663. 이벤트 로그 - The storage optimizer couldn't complete retrim on New Volume
12356정성태10/7/202074오류 유형: 662. ASP.NET Core와 500.19, 500.21 오류 (0x8007000d)
12355정성태10/3/202098오류 유형: 661. Hyper-V Linux VM의 Internal 유형의 가상 Switch에 대한 IP 연결이 되지 않는 경우
[1]  2  3  4  5  6  7  8  9  10  11  12  13  14  15  ...