일반적으로 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 
; https://docs.microsoft.com/en-us/windows/win32/sync/slim-reader-writer--srw--locks

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 (...) 구문을 사용하시는 것이 성능을 위해 더욱 현명한 선택입니다.