Life Algorithm

무지무지 오랜만의 포스팅이군요. 별로 바쁘지도 않았던 거 같은데...ㅡㅡ

시간 날 때마다 SQLite 소스를 보는 터라 -아직도 많이 부족하지만- thread-safe에 대한 포스팅을 몇 했던 만큼 SQLite의 Locking 메커니즘에 대해 간략히 적어볼까 합니다.
하지만 아시는 분은 다 아시듯 쓰고 보면 별로 안 간략하다는 거...


개  요

우선 DB에서의 lock이란 어떻게 보면 상당히 추상적인 개념이라고 할 수 있습니다.
semaphore나 pthread의 mutex같은 것은 거의 가장 하위 레벨의 원자적인 락을 위한 구현이고, DB에서의 락은 이런 것들을 이용해 좀 더 고차원적인 동시성 제어를 구현한 것입니다. 그러므로 DB의 Lock과 OS 차원에서 말하는 세마포어나 뮤텍스 등등의 락은 의미가 서로 다름을 염두에 두시기 바랍니다.

Locking Logic

SQLite는 데이터를 페이지 단위로 관리하며 페이지 단위로 락을 겁니다. 실제 데이터 파일은 페이지의 모음인 셈이지요.
SQLite의 락에는 다섯가지의 레벨이 있습니다. pthread의 rw락의 확장 스타일이라고 보면 되겠습니다(rw락은 읽기-쓰기 락이라고도 하는데 읽기 락은 동시에 여러 쓰레드가 락을 잡을 수 있지만 쓰기 락은 단 하나의 쓰레드만이 잡을 수 있습니다, 읽기만 하는 경우는 데이터 변경이 일어나지 않으므로 여러 개의 쓰레드가 동시에 읽어도 문제가 없으므로 듣기엔 꽤 좋습니다만.... 일반 mutex 락보다 느립니다 -_-).

다섯가지 레벨은 각각 Unlocked, Shared, Reserved, Pending, Exclusive인데 Shared는 읽기 락입니다. 동시에 여러 개의 쓰레드가 Shared 락을 갖고 읽을 수 있는 것입니다.
Reserved는 '내가 좀 있다 쓰기를 시작 할 거야'라는 의미의 락입니다. Reserved 락의 쓰레드가 하나 존재하면 다른 쓰레드들은 Reserved 락을 획득할 수 없습니다. 하지만 Shared를 획득하여 읽는 것은 가능합니다.
실제로 쓸 준비가 되면 Reserved 락의 쓰레드는 Pending 락을 획득합니다. Pending 상태가 되면 이제 더 이상 Shared 락이 추가되는 것이 금지되고 기존의 Shared락을 갖고 읽기를 수행하는 쓰레드들이 종료되기를 기다립니다(Shared락도 락을 얻기 전 먼저 Pending 락을 획득합니다).
Shared 락을 가진 쓰레드들이 모두 없어지면 Pending 락은 Exclusive 락으로 바뀌고 쓰기 작업을 수행합니다.

실제로 락을 요구할 때는 static 함수인 pager_wait_on_lock()을 이용해 호출하게 되는데 이는 일종의 wrapper함수이며 내부에서는 각 OS 별로 구현된 Locking 함수를 호출하게 됩니다. 컴파일시에 어떤 OS의 locking 함수를 호출할지가 결정되겠죠.

SQLite는 오라클, MySQL, PostgreSQL 등등의 여타 DB들처럼 DB 서버가 뜨고 클라이언트 툴이나 API를 이용하는 서버-클라이언트 방식이 아닌, 라이브러리를 통해 DB 파일에 직접 억세스하는 방식입니다. 다른 DB들처럼 로드 밸런싱이나 쓰레드 풀을 관리할 필요도 없고, 사용자 권한 같은 것도 관리할 필요가 없어지니(파일에 대한 Unix 계정 권한이 곧 DB권한이 되는 셈이니까요) 편하기는 하지만 서버 데몬에서 동시성 관리를 해 줄 수가 없다는 점도 있지요.

그래서 SQLite는 라이브러리 코드 내에서 mutex를 써서 멀티 쓰레드에 대한 대비를 해주면서 또한 멀티 프로세스를 위해 DB 파일에 fcntl()을 이용해 락을 겁니다.
즉, 프로세스간에든 쓰레드간에든 위에 언급한 Shared-Reserved-Pending-Exclusive 락의 구조는 동일하며 fcntl을 사용하는지 mutex를 사용하는 지가 다를 뿐입니다.


구  현

사설이 길었네요 ^^ 실제 코드를 잠깐 보지요.
실제 락을 다루는 함수는 OS별로 달리 구현되어 있지만(윈도우, 유닉스, OS/2 세 가지로 구현되어 있군요) 아는게 유닉스(or 리눅스)밖에 없으니 이 쪽만 살펴보겠습니다.

락을 거는 unixLock() 함수는 다음의 순서를 거칩니다.

1. mutex 락 획득(추가로 파일 락에 대한 ownership을 가진 쓰레드인지 확인(뒤에 설명))
2. Shared 락의 경우 다른 Shared 락이나 Reserved 락이 존재하면 락의 카운트만 증가시키고 종료
3. Pending 락을 파일에 건다.
4. Share 락인 경우 read lock을 파일에 걸고 Pending 락은 해제
5. Reserved나 Exclusive인 경우 write lock을 파일에 건다(다른 락이 진입을 시도하다가 Pending락을 발견하고 락 획득을 취소시켜야 하므로 Pending은 해제하지 않는다)
6. mutex 해제

위에서 5번 같은 경우 Reserved나 Exclusive랑 Pending이 같이 걸릴 수 있는 것 처럼 써놨는데 실제로 같이 걸립니다. fcntl은 파일 전체에 락을 거는게 아니라 원하는 옵셋에 원하는 바이트만큼 락을 걸기 때문에 SQLite는 Shared, Pending, Reserved 영역을 구분해 놓고 락을 걸도록 되어 있습니다(Exclusive는 Shared와 Pending에 동시에 락을 걸게 되므로 영역이 따로 없습니다).

경우에 따라 순서가 다르긴 하지만 기본적으로는 fcntl을 상황에 따라 다르게 사용하는 코드이므로 모두 볼 필요는 없고 4번의 경우를 한 번 보겠습니다(indentation이 좀 이상하군요 -_-).

/* SHARED_LOCK인 경우 fcntl으로 SHARED에 read 락을 걸고
** PENDING 락은 해제한다
*/
if( locktype==SHARED_LOCK ){
        /* SHARED_LOCK의 지정 옵셋에 read-lock 획득,
** l_type은 이미 3번 과정에서 지정됨 */
        lock.l_start = SHARED_FIRST;
        lock.l_len = SHARED_SIZE;
        s = fcntl(pFile->h, F_SETLK, &lock);

        /* 임시로 걸었던 PENDING 락 해제 */
        lock.l_start = PENDING_BYTE;
        lock.l_len = 1L;
        lock.l_type = F_UNLCK;
        if( fcntl(pFile->h, F_SETLK, &lock)!=0 ){
                rc = SQLITE_IOERR;
                goto end_lock;
        }
        if( s ){
                rc = (errno==EINVAL) ? SQLITE_NOLFS : SQLITE_BUSY;
        }else{
                pFile->locktype = SHARED_LOCK;
                pFile->pOpen->nLock++;
                pLock->cnt = 1;
        }
}


 

 

물론 SHARED_FIRST, SHARED_SIZE, PENDING_BYTE등은 매크로로 지정되어 있는 숫자들이구요.
마지막에는 구조체의 파일 락 카운트와 락 카운트를 1씩 증가시키고 끝냅니다. pFile->pOpen->nLock은 파일에 대한 락의 갯수이며, pLock->cnt는 락 자체의 카운트입니다(SHARED가 아니라면 1을 넘어갈 수 없겠죠).

위의 코드는 파일에 대한 락이므로 프로세스 간에는 관리가 되지만, 실제 파일을 다루지 않고 있던 쓰레드가 파일에 대한 락을 획득하려고 할 경우는 뮤텍스와 상관없이 문제가 될 수 있습니다.
이를 위해서 SQLite는 락 정보에 대한 해쉬 테이블을 유지하면서 필요시마다 thread id를 비교하여 올바른 쓰레드만이 파일 락에 접근할 수 있도록 제어하고 있습니다. 이 부분이 1번 과정의 ()의 내용에 대한 것입니다.

그럼 마지막으로 위의 과정들을 수행하기 전 뮤텍스 락을 어떤 방식으로 획득하는지 살펴 보지요.
단순히 pthread_mutex_lock만 하는 건 아니거든요. ^^


void sqlite3UnixEnterMutex(){
        /* 보조 뮤텍스 획득 */
        pthread_mutex_lock(&mutexAux);

        /* 메인 뮤텍스가 풀려 있는 상태거나
         * 현재 메인 뮤텍스를 가진 쓰레드가 아닐 경우 */
        if( !mutexOwnerValid || !pthread_equal(mutexOwner, pthread_self()) ){
                /* 보조 뮤텍스 풀고 메인 뮤텍스 획득 */
                pthread_mutex_unlock(&mutexAux);
                pthread_mutex_lock(&mutexMain);

                /* 다시 보조 뮤텍스 획득 */
                pthread_mutex_lock(&mutexAux);

                /* 뮤텍스 소유자로 쓰레드 자신을 지정,
                 * 소유 플래그 셋팅 */
                mutexOwner = pthread_self();
                mutexOwnerValid = 1;
        }

        /* 카운터 증가시키고 보조 뮤텍스 해제 */
        inMutex++;
        pthread_mutex_unlock(&mutexAux);
}


보시다시피, 실제로는 두 개의 mutex 변수를 쓰고 있습니다.
하나는 실제 락을 위한 메인 뮤텍스이며 하나는 뮤텍스 정보 저장을 위한 변수 억세스에 쓰이는 보조 뮤텍스입니다.
mutexOwner는 메인 뮤텍스를 갖고 있는 쓰레드의 tid, mutexOwnerValid는 뮤텍스를 갖고 있는 쓰레드가 있으면 1로 세팅되는 플래그 변수이며 inMutex는 같은 쓰레드가 여러 번 뮤텍스를 요구할 경우 증가하는 카운터입니다.

실제로 뮤텍스를 같은 쓰레드가 새로 획득하려고 시도하는 것은 Undefined Behavior입니다. 리눅스 같은 경우 데드락이 걸리더군요. Recursive Mutex를 위해서는 뮤텍스 타입을 PTHREAD_MUTEX_RECURSIVE으로 지정하면 되긴 합니다만, 위와 같은 방식이 아마 성능이 좀 더 낫다든가 하는 이유가 있겠죠 -0-

...아직도 잘 모르는 처지에 나름대로 소스 분석을 하고 글까지 쓰려니 시간이 많이 드는군요. 아직 저도 이해 안되는 부분들도 있고...^^;
소스는 SQLite-3.3.6 기준이므로 현재 버전과는 차이가 좀 있을 수 있습니다.

이번 글은 여기서 마치며... 담에 기회되면 다른 주제로 또 쓰도록 하겠습니다. 질문있는 분은 허심탄회하게 댓글로~