yuchi's development

Windows Vista부터 추가된 스레드 동기화 API가 있다.
AcquireSRWLockExclusive()/ReleaseSRWLockExclusive()
AcquireSRWLockShared()/ ReleaseSRWLockShared() 가 그것이다.
뭐 함수이름을 보면 금방 눈치챌 수 있듯이 여러 스레드가 동시에 락을 읽기 전용으로 획득하려고 AcquireSRWLockShared()를 호출한다면 대기없이 않고 바로 락을 통과한다. 쓰기 작업을 해야할 경우 AcquireSRWLockExclusive()를 호출하면 된다. 이 경우는 다른 스레드가 AcquireSRWLockShared()로 락을 획득하려고 하는 경우에도 무조건 락이 걸린다.

이게 중요한게 아니고…
이 함수의 내부 구현에 대해서 얘기해보고자 한다.
이 함수는 굉장히 빠르다. 무슨 얘기나면 락을 획득하는 과정-

1)다른 스레드가 점유하지 않은 락을 먼저 획득하는 경우,
2)다른 스레드가 먼저 점유한 락을 대기하다가 획득하는 경우,

모두 빠르다. 예전엔 그래도 Critical Seciton이 빠르다고 알려져 있었지만 비교도 안되게 빠르다. 응답성이 확실히 좋다.
이게 어떻게 가능할까?

간단히 EnterCriticalSectionAndSpinCount()처럼 내부적으로 Spin-Count를 이용할거라고 추측할 수 있다. 그러니까 대기중이다가도 다른 스레드 빠져나가면 번개같이 락을 획득할 수 있겠지.
Critial Section의 SpinCount를 설정하지 않는 경우, 락이 이미 걸려있으면 시스템콜을 호출하고 해당 스레드는 wait상태로 들어간다. cpu자원을 점유하지 않는다.
문제는 이 상태가 되면 다른 스레드가 LeaveCriticalSection()을 호출해도 대기하던 스레드가 다시 스케쥴링될때까지 시간이 꽤 걸린다. cpu점유율이야 낮을지 모르지만 응답성에선 손해를 꽤 본다.
그리고 이를 보완하기 위해서 EnterCriticalSectionAndSpinCount()에 스핀카운트를 설정해서 임의의 회수만큼 락을 획득하기 위한 시도를 먼저 해볼수 있다.

Critial Section의 경우로 확인할 수 있듯이 Spin-Count를 사용하는 것이 일단 응답성을 높이는 확실한 방법이다. SRWLock도 Spin-Count를 사용한다.

SRWLock은 다음과 같이 작동한다.

1. 첫번째 스레드가 진입한다.
   • SRWLOCK 구조체의 Ptr값이 0이다. Ptr의 0번째 비트를 검사한다.
   • 비트가 0이라면 ptr의 0번 비트를 1로 설정하고(0b01) 그대로 빠져나간다.
   • OK. 이제 락이 걸린 상태고 경쟁상태는 아니다.
2. 두번째 스레드가 진입한다.
   • SRWLOCK 구조체의 Ptr값은 1이다.Ptr의 0번째 비트를 검사한다.
   • 비트가 0이 아니므로 그대로 빠져나갈 수 없다.
   • Ptr의 내용(이하 락변수의 내용이라 칭한다)을 다른 메모리에 카피하고 Ptr은 그 어드레스를 가진다. 정확히는 Ptr의 내용을 포함하는 구조체의 어드레스를 가진다. 그리고 그 메모리는 지금 진입한 스레드의 stack공간이다. 즉 지금 진입한 스레드의 로컬변수이다. 세번째 스레드가 진입했을땐 Ptr변수로부터 비트테스트를 바로 하지 않고 Ptr변수가 가리키는 락변수의 비트를 검사하게 된다.
   • 락변수의 1번째 비트를 1로 설정한다(0b11). 이제 경쟁상태이다.
   • 두번째 스레드는 1024번 루프를 돌며 pause명령을 수행한다.
   • SRWLOCK Ptr이 가리키는 메모리-락변수의 1번째 비트를 btr 명령으로 검사하고 0으로 세팅한다. 여기서 다음과 같이 분기가 갈린다.
   • 첫번째 스레드가 RelaseSRWLockXXXX()을 호출하여 락을 해제한 경우.
     • 락변수의 1번 비트값이 0이다(0b01). 이제 두번째 스레드가 락을 획득한 상태이고 경쟁하지 않는 상태이다.
   • 첫번째 스레드가 아직 ReleaseSRWLockXXXX()를 호출하지 않은 경우.즉 아직 락을 쥐고 있는 경우.
     • 락변수의 1번 비트값이 1이다(0b11). 이 경우 1024번의 루프를 돌며 대기했지만 락을 획득하지 못했으므로 call _NtWaitForAlertByThreadId@8 를 수행하여 대기 상태(스레드가 스케쥴링 되지 않은 상태)로 진입한다.

void AcquireSpinLock(volatile LONG* plCount)
{
LONG	lOldCount;

lb_try:
lOldCount = _InterlockedCompareExchange(plCount,1,0);

if (lOldCount)
{
goto lb_try;
}

}
void ReleaseSpinLock(volatile LONG* plCount)
{
_InterlockedDecrement(plCount);
}

void TestSpinlock()
{
AcquireSpinLock(&g_lSpinLock);
g_dwCount++;
ReleaseSpinLock(&g_lSpinLock);
}
void TestSRWLock()
{
AcquireSRWLockExclusive(&g_SRWLock);
g_dwCount++;
ReleaseSRWLockExclusive(&g_SRWLock);
}
void TestCriticalSection()
{
EnterCriticalSection(&g_cs);
g_dwCount++;
LeaveCriticalSection(&g_cs);
}

void AcquireSpinLockWithYield(volatile LONG* plCount)
{
LONG	lOldCount;

lb_try:
lOldCount = _InterlockedCompareExchange(plCount,1,0);

if (lOldCount)
{
for (DWORD i = 0; i < 1024; i++)
{
YieldProcessor();	// __asm pause
}
goto lb_try;
}

}

기대한대로 빨라졌다. 가장 빠르다. 물론 SRWLock대신 이렇게 만들어쓰자는 얘기는 아니다. SRWLock의 성능의 비결이 바로 저것이라는 얘기를 하고 싶었다.

MVP 짤렸지만 아직 기간이 만료된건 아니라서 Windows 소스코드 열람하려면 할순 있을텐데 그냥 어셈코드 보고 분석했다. 몇시간 봤더니 눈이 침침하네.