ReaderWriterLockSlim 은 언제 쓰는 걸까요? [출처] ReaderWriterLockSlim 은 언제 쓰는 걸까요?|작성자 techshare

http://blog.naver.com/techshare/100143985194
위 블로그에서 퍼온글입니다.

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

.NET 참조 개체 인스턴스의 SyncBlock 을 확인하는 방법
; http://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 (...) 구문을 사용하시는 것이 성능을 위해 더욱 현명한 선택입니다.

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

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