postgresql源码学习（九）—— 常规锁②-强弱锁与Fast Path

一、 强锁与弱锁

         根据兼容性表，彼此相容的3个锁（1-3级，AccessShareLock、RowShareLock、RowExclusiveLock）是弱锁，4级锁ShareUpdateExclusiveLock比较特殊，既不是强锁也不是弱锁，5-8级的4个则是强锁。

       弱锁只保存在当前会话，从而避免频繁访问共享内存的主锁表，提高数据库的性能。虽然判断是否有强锁也需要访问共享内存中的FastPathStrongRelationLocks，但这种访问粒度比较小。

二、 Fast Path检查

        按照常规锁获取步骤，如果本地锁表中没有找到这个锁对象和锁模式，就需要进到第二步Fast Path检查。

1. 检查条件

         Fast Path检查分两部分：弱锁部分与强锁部分，pg分别使用两个宏来判断（lock.c）。

// 弱锁需要满足4个条件：
// 1. 默认lock method；2. 对表加锁；3. 当前db；4. 锁模式小于ShareUpdateExclusiveLock（4级锁）
#define EligibleForRelationFastPath(locktag, mode) \
	((locktag)->locktag_lockmethodid == DEFAULT_LOCKMETHOD && \
	(locktag)->locktag_type == LOCKTAG_RELATION && \
	(locktag)->locktag_field1 == MyDatabaseId && \
	MyDatabaseId != InvalidOid && \
	(mode) < ShareUpdateExclusiveLock)

// 强锁也需要满足4个条件：
// 只有第4个为锁模式大于ShareUpdateExclusiveLock（4级锁），其余3个与弱锁相同
#define ConflictsWithRelationFastPath(locktag, mode) \
	((locktag)->locktag_lockmethodid == DEFAULT_LOCKMETHOD && \
	(locktag)->locktag_type == LOCKTAG_RELATION && \
	(locktag)->locktag_field1 != InvalidOid && \
	(mode) > ShareUpdateExclusiveLock)

注意判断的时候都没有mode = ShareUpdateExclusiveLock，因为它既不是强锁也不是弱锁。

2. 弱锁申请时

       一个弱锁能够直接获得而不经过主锁表，需要判断两个条件：

• 共享内存中是否设置了强锁标记

       如果共享内存中没有设置强锁标记，说明当前没有其他事务获得过这个锁对象的强锁模式。因此事务在这个对象间不会有冲突，此时可以考虑获得这个弱锁。

• 当前进程是否还有空间可以保存弱锁

       如果弱锁保存在本事务的fast path中，实际上它是保存在PGPROC中的（以下代码在proc.h）。

#define		FP_LOCK_SLOTS_PER_BACKEND 16

	/* Lock manager data, recording fast-path locks taken by this backend. */
	LWLock		fpInfoLock;		/* protects per-backend fast-path state */
	uint64		fpLockBits;		/* lock modes held for each fast-path slot */
	Oid			fpRelId[FP_LOCK_SLOTS_PER_BACKEND]; /* slots for rel oids */

       PGPROC->fpRelId是一个长度为16的数组，里面保存的是表的oid，因此最多保存16个弱锁。

       PGPROC->fpLockBits保存的是一个位图，目前64位中（uint64）只用了48位。每3位组成一个槽（因为共有3种弱锁），每个槽都与PGPROC->fpRelId数组中的表对应（所以3*16=48）。

/* Macros for manipulating proc->fpLockBits，3种弱锁所以每3位组成一个槽*/
#define FAST_PATH_BITS_PER_SLOT		3
#define FAST_PATH_LOCKNUMBER_OFFSET		1
//形式为111的掩码
#define FAST_PATH_MASK					((1 << FAST_PATH_BITS_PER_SLOT) - 1)
//得到第n个槽中已有的锁模式
#define FAST_PATH_GET_BITS(proc, n) \
	(((proc)->fpLockBits >> (FAST_PATH_BITS_PER_SLOT * n)) & FAST_PATH_MASK)

       所以当一个事务要对弱锁使用fast path时，就尝试在PGPROC->fpLockBits中记录当前的锁模式，事务就能够获得锁了。

       当然，如果记录的弱锁数超过了16，那也需要去主锁表中检查。

3. 强锁申请时

如果要申请的强锁模式，需要做的事如下：

• 设置强锁标记，即 FastPathStrongRelationLocks->count（也是一个数组）的引用计数加1
• 把其他事务保存的对应弱锁转移到主锁表中，方便死锁检测（因为有强锁之后就会有等待）

源码实现部分较长，为了结构清晰一些，我们单独放下面。

三、 强锁申请时的fast path操作

1. 设置强锁标记

• FastPathStrongRelationLocks的定义

typedef struct
{
	slock_t		mutex;
	uint32		count[FAST_PATH_STRONG_LOCK_HASH_PARTITIONS]; //数组最大长度1024
} FastPathStrongRelationLockData;

static volatile FastPathStrongRelationLockData *FastPathStrongRelationLocks;

• 强锁获取函数

       核心是FastPathStrongRelationLocks->count[fasthashcode]++; 以及 locallock->holdsStrongLockCount = true;

/*
 * BeginStrongLockAcquire - inhibit use of fastpath for a given LOCALLOCK,
 * and arrange for error cleanup if it fails
 */
static void
BeginStrongLockAcquire(LOCALLOCK *locallock, uint32 fasthashcode)
{
	Assert(StrongLockInProgress == NULL);
	Assert(locallock->holdsStrongLockCount == false);

	/*
	 * Adding to a memory location is not atomic, so we take a spinlock to
	 * ensure we don't collide with someone else trying to bump the count at
	 * the same time.
	 *
	 * XXX: It might be worth considering using an atomic fetch-and-add
	 * instruction here, on architectures where that is supported.
	 */

	SpinLockAcquire(&FastPathStrongRelationLocks->mutex);
	FastPathStrongRelationLocks->count[fasthashcode]++;  //注意这里，强锁引用计数加1
	locallock->holdsStrongLockCount = true;
	StrongLockInProgress = locallock;
	SpinLockRelease(&FastPathStrongRelationLocks->mutex);
}

2. 弱锁转移到主锁表中

       把其他事务保存的对应弱锁转移到主锁表中。整体就是3个大循环：检查每个进程中的、每个表的、3种弱锁模式是否设置过。

/*
 * FastPathTransferRelationLocks
 *		Transfer locks matching the given lock tag from per-backend fast-path
 *		arrays to the shared hash table.
 *
 * Returns true if successful, false if ran out of shared memory.
 */
static bool
FastPathTransferRelationLocks(LockMethod lockMethodTable, const LOCKTAG *locktag,
							  uint32 hashcode)
{
	LWLock	   *partitionLock = LockHashPartitionLock(hashcode);
	Oid			relid = locktag->locktag_field2;
	uint32		i;

/*
	 * Every PGPROC that can potentially hold a fast-path lock is present in
	 * ProcGlobal->allProcs.  Prepared transactions are not, but any
	 * outstanding fast-path locks held by prepared transactions are
	 * transferred to the main lock table.
* 每个PGPROC都有可能持有fast-path锁（在ProcGlobal->allProcs数组中），因此需要循环遍历所有PGPROC。所有prepared阶段之后的事务需要将fast-path locks转移到主锁表。
	 */
	for (i = 0; i < ProcGlobal->allProcCount; i++)
	{
		PGPROC	   *proc = &ProcGlobal->allProcs[i];
		uint32		f;

		LWLockAcquire(&proc->fpInfoLock, LW_EXCLUSIVE);

/*
		 * If the target backend isn't referencing the same database as the
		 * lock, then we needn't examine the individual relation IDs at all;
		 * none of them can be relevant.
如果进程引用的库跟要求加锁的对象都不是同一个，那么不需再检查其中的表，直接跳过本次循环，换下一个检查
*/ 

		if (proc->databaseId != locktag->locktag_field1)
		{
			LWLockRelease(&proc->fpInfoLock);
			continue;
		}

		/*	
		 * 如果是同一个库，那么遍历16个针对表的槽
		 */
		for (f = 0; f < FP_LOCK_SLOTS_PER_BACKEND; f++)
		{
			uint32		lockmode;

			/* 如果不是同一个表，或者当前没有弱锁，则跳出循环，换下一个表 */
			if (relid != proc->fpRelId[f] || FAST_PATH_GET_BITS(proc, f) == 0)
				continue;

			/* 否则，继续按lockmode循环检查3类弱锁。FAST_PATH_LOCKNUMBER_OFFSET=1，FAST_PATH_BITS_PER_SLOT=3，所以其实就是for (lockmode = 1; lockmode < 1+3; ++lockmode)
 */
			LWLockAcquire(partitionLock, LW_EXCLUSIVE);
			for (lockmode = FAST_PATH_LOCKNUMBER_OFFSET;
				 lockmode < FAST_PATH_LOCKNUMBER_OFFSET + FAST_PATH_BITS_PER_SLOT;
				 ++lockmode)
			{
				PROCLOCK   *proclock;

			/* 检查3个弱锁的标记是否被设置过，如果没有，代表fast path中没出现过这个锁模式，换下一个 */
				if (!FAST_PATH_CHECK_LOCKMODE(proc, f, lockmode))
					continue;
			/* 否则，把这个锁模式挪到共享内存。SetupLockInTable函数的主要作用就是在主锁表和进程锁表中查找对应的锁，如果该锁不存在，则在主锁表和进程锁表中申请内存保存锁并初始化锁信息。我们会在下篇中重点学习这个函数。
 */
				proclock = SetupLockInTable(lockMethodTable, proc, locktag,
											hashcode, lockmode);
				if (!proclock) // Returns false if ran out of shared memory
				{
					LWLockRelease(partitionLock);
					LWLockRelease(&proc->fpInfoLock);
					return false;
				}
                 // 增加本地锁的计数 
				GrantLock(proclock->tag.myLock, proclock, lockmode);
                 // 在PGPROC中去掉对应锁模式，业务PGPROC已转移到主锁表
				FAST_PATH_CLEAR_LOCKMODE(proc, f, lockmode);
			}
			LWLockRelease(partitionLock);

			/* No need to examine remaining slots. */
			break;
		}
		LWLockRelease(&proc->fpInfoLock);
	}
	return true;
}

参考

《PostgreSQL技术内幕：事务处理深度探索》第2章