在上一篇文章中介紹了SQLite怎么用Linux中的記錄鎖來實現每一種類型的事務鎖。但這只適合多進程間的互斥，不適合多線程，在Linux中每一個進程只能擁有一把鎖，也就是說一個進程里的多個線程共用一把鎖，這時會出現一個線程擁有共享鎖，另一個線程再獲取獨占鎖時并不會出現排斥，僅僅是把當前進程的鎖改為獨占鎖，還有當一個線程占有鎖的時候可能被另一個線程釋放等等，這就破壞了數據庫中多事務的隔離性。所以SQLite在進程內部自己維護著每個事務對文件鎖的擁有情況。

1.inode

為了管理進程內部的鎖，首先需要對每個文件做唯一標識，SQLite使用文件的inode作為唯一標識。要注意不能用文件描述符，因為Linux中存在一個文件是另一個文件的硬連接或軟連接(可以理解成類似快捷方式的東西)，它們雖然有不同文件名，打開的文件描述符不同，實際上對應著同一個文件。

每打開一個事務連接，SQLite會通過fstat()函數尋找對應的文件的inode，并關聯到連接句柄中。如果是第一次打開文件，則把對應的inode插到全局鏈表inodeList中。

static int findInodeInfo(
  unixFile *pFile,               /* Unix file with file desc used in the key */
  unixInodeInfo **ppInode        /* Return the unixInodeInfo object here */
){
  int rc;                        /* System call return code */
  int fd;                        /* The file descriptor for pFile */
  struct unixFileId fileId;      /* Lookup key for the unixInodeInfo */
  struct stat statbuf;           /* Low-level file information */
  unixInodeInfo *pInode = 0;     /* Candidate unixInodeInfo object */

  assert( unixMutexHeld() );

  /* Get low-level information about the file that we can used to
  ** create a unique name for the file.
  */
  fd = pFile->h;
  rc = osFstat(fd, &statbuf);
  if( rc!=0 ){
    storeLastErrno(pFile, errno);
    return SQLITE_IOERR;
  }
  memset(&fileId, 0, sizeof(fileId));
  fileId.dev = statbuf.st_dev;
#if OS_VXWORKS
  fileId.pId = pFile->pId;
#else
  fileId.ino = (u64)statbuf.st_ino;
#endif
  pInode = inodeList;
  while( pInode && memcmp(&fileId, &pInode->fileId, sizeof(fileId)) ){
    pInode = pInode->pNext;
  }
  if( pInode==0 ){
    pInode = sqlite3_malloc64( sizeof(*pInode) );
    if( pInode==0 ){
      return SQLITE_NOMEM_BKPT;
    }
    memset(pInode, 0, sizeof(*pInode));
    memcpy(&pInode->fileId, &fileId, sizeof(fileId));
    pInode->nRef = 1;
    pInode->pNext = inodeList;
    pInode->pPrev = 0;
    if( inodeList ) inodeList->pPrev = pInode;
    inodeList = pInode;
  }else{
    pInode->nRef++;
  }
  *ppInode = pInode;
  return SQLITE_OK;
}

在SQLite中用unixInodeInfo對象來保存每個inode相關信息，每個文件只能有一個inode，這里記錄了該文件在進程內鎖的分配情況，每一個事務連接都有一個pInode指針來指向unixInodeInfo對象。

下圖描述了一個進程內的3個事務打開同一個數據庫文件，其中有2個線程，其中一個線程包含2個事務。

在unixFile對象里，h為每個連接的句柄，eFileLock為事務當前鎖的類型。在unixInodeInfo對象里，nRef為文件對應的連接數，eFileLock為所有連接中等級最高的鎖，nShared為當前鎖的個數。

2.鎖的實現

在sqlite中事務鎖的接口為：

int sqlite3OsLock(sqlite3_file *id, int lockType)

int sqlite3OsUnlock(sqlite3_file *id, int lockType)

在Linux中對應的接口是：

   static int unixLock(sqlite3_file *id, int eFileLock)

static int unixUnlock(sqlite3_file *id, int eFileLock)

下面就來講解SQLite是如何在進程內部管理鎖的分配，每個鎖的對應狀態的宏定義如下，數字越大等級越高

#define NO_LOCK         0
#define SHARED_LOCK     1
#define RESERVED_LOCK   2
#define PENDING_LOCK    3
#define EXCLUSIVE_LOCK  4 

加鎖時傳入的參數為連接句柄和鎖的類型，unixLock()實現了具體的流程，pFile->eFileLock表示當前連接的鎖，eFileLock為當前連接需要獲取的鎖，pInode->eFileLock為文件在當前進程中的鎖，以下是這幾個變量的關系

if (pFile->eFileLock>=eFileLock) 
    return SQLITE_OK
else if(pInode->eFileLock >= PENDING_LOCK)
    此時必定有其他線程申請了獨占鎖
    return SQLITE_OK
else
     switch (eFileLock)
     case NO_LOCK:
          此時必定有pFile->eFileLock>=eFileLock，所以不
          可能出現這種情況。
     case SHARED_LOCK:
          此時pFile->eFileLock == NO_LOCK，pInode->
          eFileLock <= RESERVED_LOCK，可以正常申請鎖
     case RESERVED_LOCK:
           此時pFile->eFileLock == SHARED_LOCK，如果
           pInode->eFileLock==RESERVED_LOCK將返回busy
     case EXCLUSIVE_LOCK:
           如果pInode->eFileLock==RESERVED_LOCK將返回
           busy，不管pFile->eFileLock是什么

static int unixLock(sqlite3_file *id, int eFileLock){
  int rc = SQLITE_OK;
  unixFile *pFile = (unixFile*)id; 
  unixInodeInfo *pInode;
  struct flock lock;
  int tErrno = 0;

  assert( pFile );

  // 判斷1：eFileLock比當前鎖的等級高才加鎖
  if( pFile->eFileLock>=eFileLock ){
    return SQLITE_OK;
  }

  /* Make sure the locking sequence is correct.
  **  (1) We never move from unlocked to anything higher than shared lock.
  **  (2) SQLite never explicitly requests a pendig lock.
  **  (3) A shared lock is always held when a reserve lock is requested.
  */
 //斷言1：當pFile->eFileLock=NO_LOCK時，只能加共享鎖
  assert( pFile->eFileLock!=NO_LOCK || eFileLock==SHARED_LOCK );
 //斷言2：Pending鎖是內部鎖，不能由外部事務獲取
  assert( eFileLock!=PENDING_LOCK );
 //斷言3：只有在共享鎖的基礎上才能申請Reserved鎖
  assert( eFileLock!=RESERVED_LOCK || pFile->eFileLock==SHARED_LOCK );

  /* This mutex is needed because pFile->pInode is shared across threads
  */
  unixEnterMutex();
 //獲取當前連接對應的inode
  pInode = pFile->pInode;

  /* If some thread using this PID has a lock via a different unixFile*
  ** handle that precludes the requested lock, return BUSY.
  */
  //如果有其他連接擁有了Pending鎖，返回busy
  //由定義可知pInode->eFileLock >= pFile->eFileLock
  //當eFileLock>SHARED_LOCK,由斷言1和pFile->eFileLock!=pInode-> eFileLock知pInode->eFileLock> SHARED_LOCK
 //當pFile->eFileLock==pInode->eFileLock，那么只能是NO_LOCK或SHARED_LOCK狀態，此時不可能出現排斥狀態
//等價于(pInode->eFileLock>=PENDING_LOCK)||((pFile->eFileLock == RESERVED_LOCK)&&(eFileLock>SHARED_LOCK))
  if( (pFile->eFileLock!=pInode->eFileLock && 
          (pInode->eFileLock>=PENDING_LOCK || eFileLock>SHARED_LOCK))
  ){
    rc = SQLITE_BUSY;
    goto end_lock;
  }
 
  /* If a SHARED lock is requested, and some thread using this PID already
  ** has a SHARED or RESERVED lock, then increment reference counts and
  ** return SQLITE_OK.
  */
  //獲取的是共享鎖，但是其他線程已經擁有共享鎖或Reserved鎖，此時無需對文件加鎖，只需在pInode和pFile里記錄信息即可
  if( eFileLock==SHARED_LOCK && 
      (pInode->eFileLock==SHARED_LOCK || pInode->eFileLock==RESERVED_LOCK) ){
    assert( eFileLock==SHARED_LOCK );
    assert( pFile->eFileLock==0 );
    assert( pInode->nShared>0 );
    pFile->eFileLock = SHARED_LOCK;
    pInode->nShared++;
    pInode->nLock++;
    goto end_lock;
  }


  /* A PENDING lock is needed before acquiring a SHARED lock and before
  ** acquiring an EXCLUSIVE lock.  For the SHARED lock, the PENDING will
  ** be released.
  */
 //如果進程是第一次獲取共享鎖，或者獲取獨占鎖時都需要先獲取Pending鎖
  lock.l_len = 1L;
  lock.l_whence = SEEK_SET;
  if( eFileLock==SHARED_LOCK 
      || (eFileLock==EXCLUSIVE_LOCK && pFile->eFileLock<PENDING_LOCK)
  ){
    lock.l_type = (eFileLock==SHARED_LOCK?F_RDLCK:F_WRLCK);
lock.l_start = PENDING_BYTE;
//如果獲取失敗，說明已經有其他進程擁有Pending鎖或獨占鎖
    if( unixFileLock(pFile, &lock) ){
      tErrno = errno;
      rc = sqliteErrorFromPosixError(tErrno, SQLITE_IOERR_LOCK);
      if( rc!=SQLITE_BUSY ){
        storeLastErrno(pFile, tErrno);
      }
      goto end_lock;
    }
  }


  /* If control gets to this point, then actually go ahead and make
  ** operating system calls for the specified lock.
  */
  if( eFileLock==SHARED_LOCK ){
    assert( pInode->nShared==0 );
    assert( pInode->eFileLock==0 );
    assert( rc==SQLITE_OK );
    
    /* Now get the read-lock */
    lock.l_start = SHARED_FIRST;
lock.l_len = SHARED_SIZE;
//此時已經擁有Pending鎖，SHARED_FIRST區域不可能有寫鎖
//所以理論上在SHARED_FIRST區域獲取讀鎖并不會失敗
    if( unixFileLock(pFile, &lock) ){
      tErrno = errno;
      rc = sqliteErrorFromPosixError(tErrno, SQLITE_IOERR_LOCK);
    }
    //獲取到共享鎖后釋放Pending鎖
    /* Drop the temporary PENDING lock */
    lock.l_start = PENDING_BYTE;
    lock.l_len = 1L;
    lock.l_type = F_UNLCK;
    if( unixFileLock(pFile, &lock) && rc==SQLITE_OK ){
      /* This could happen with a network mount */
      tErrno = errno;
      rc = SQLITE_IOERR_UNLOCK; 
    }

    if( rc ){
      if( rc!=SQLITE_BUSY ){
        storeLastErrno(pFile, tErrno);
      }
      goto end_lock;
}else{
  //修改鎖的相關信息
      pFile->eFileLock = SHARED_LOCK;
      pInode->nLock++;
      pInode->nShared = 1;
    }
  }else if( eFileLock==EXCLUSIVE_LOCK && pInode->nShared>1 ){
    /* We are trying for an exclusive lock but another thread in this
** same process is still holding a shared lock. */
// pInode->nShared>1說明還有其他線程擁有共享鎖
    rc = SQLITE_BUSY;
  }else{
    /* The request was for a RESERVED or EXCLUSIVE lock.  It is
    ** assumed that there is a SHARED or greater lock on the file
    ** already.
    */
    assert( 0!=pFile->eFileLock );
    lock.l_type = F_WRLCK;

    assert( eFileLock==RESERVED_LOCK || eFileLock==EXCLUSIVE_LOCK );
    if( eFileLock==RESERVED_LOCK ){
      lock.l_start = RESERVED_BYTE;
      lock.l_len = 1L;
    }else{
      lock.l_start = SHARED_FIRST;
      lock.l_len = SHARED_SIZE;
    }
    //如果還有其他進程擁有Reserved以上等級的鎖，將會獲取失敗
    if( unixFileLock(pFile, &lock) ){
      tErrno = errno;
      rc = sqliteErrorFromPosixError(tErrno, SQLITE_IOERR_LOCK);
      if( rc!=SQLITE_BUSY ){
        storeLastErrno(pFile, tErrno);
      }
    }
  }
  
  //根據判斷1可知 pInode->eFileLock>=pFile->eFileLock
  if( rc==SQLITE_OK ){
    pFile->eFileLock = eFileLock;
    pInode->eFileLock = eFileLock;
  }else if( eFileLock==EXCLUSIVE_LOCK ){
    //說明還有其他進程有鎖，等待其釋放
    pFile->eFileLock = PENDING_LOCK;
    pInode->eFileLock = PENDING_LOCK;
  }

end_lock:
  unixLeaveMutex();
  return rc;
}

unixUnlock的實現就比較簡單，在此簡單說明一下：

if (pFile->eFileLock>=eFileLock) 
    此時已經有更低級的鎖，無需任何操作
    return SQLITE_OK
if(pFile->eFileLock > SHARED_LOCK)
    此時根據鎖的協議，不可能存在由獨占鎖降到Reserved鎖
    的情況，所以eFileLock為NO_LOCK或共享鎖
    if(eFileLock == SHARED_LOCK)
        把鎖頁中的Shared byte區域設為讀鎖
    清除Pending byte和Reserved byte區域的寫鎖
if(eFileLock == NO_LOCK)
    pInode->nShared--
    if(pInode->nShared == 0)
         清除這個文件的所有鎖