PostgreSQL Locks中LOCK结构体是什么

发布时间:2021-11-08 16:23:27 作者:iii
来源:亿速云 阅读:145

本篇内容主要讲解“PostgreSQL Locks中LOCK结构体是什么”,感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷,实用性强。下面就让小编来带大家学习“PostgreSQL Locks中LOCK结构体是什么”吧!

一、LOCK Struct

/*
 * The LOCKTAG struct is defined with malice aforethought to fit into 16
 * bytes with no padding.  Note that this would need adjustment if we were
 * to widen Oid, BlockNumber, or TransactionId to more than 32 bits.
 *
 * We include lockmethodid in the locktag so that a single hash table in
 * shared memory can store locks of different lockmethods.
 */
typedef struct LOCKTAG
{
    uint32      locktag_field1; /* a 32-bit ID field */
    uint32      locktag_field2; /* a 32-bit ID field */
    uint32      locktag_field3; /* a 32-bit ID field */
    uint16      locktag_field4; /* a 16-bit ID field */
    uint8       locktag_type;   /* see enum LockTagType */
    uint8       locktag_lockmethodid;   /* lockmethod indicator */
} LOCKTAG;
/*
 * Per-locked-object lock information:
 *
 * tag -- uniquely identifies the object being locked
 * grantMask -- bitmask for all lock types currently granted on this object.
 * waitMask -- bitmask for all lock types currently awaited on this object.
 * procLocks -- list of PROCLOCK objects for this lock.
 * waitProcs -- queue of processes waiting for this lock.
 * requested -- count of each lock type currently requested on the lock
 *      (includes requests already granted!!).
 * nRequested -- total requested locks of all types.
 * granted -- count of each lock type currently granted on the lock.
 * nGranted -- total granted locks of all types.
 *
 * Note: these counts count 1 for each backend.  Internally to a backend,
 * there may be multiple grabs on a particular lock, but this is not reflected
 * into shared memory.
 */
typedef struct LOCK
{
    /* hash key */
    LOCKTAG     tag;            /* unique identifier of lockable object */
    /* data */
    LOCKMASK    grantMask;      /* bitmask for lock types already granted */
    LOCKMASK    waitMask;       /* bitmask for lock types awaited */
    SHM_QUEUE   procLocks;      /* list of PROCLOCK objects assoc. with lock */
    PROC_QUEUE  waitProcs;      /* list of PGPROC objects waiting on lock */
    int         requested[MAX_LOCKMODES];   /* counts of requested locks */
    int         nRequested;     /* total of requested[] array */
    int         granted[MAX_LOCKMODES]; /* counts of granted locks */
    int         nGranted;       /* total of granted[] array */
} LOCK;
#define LOCK_LOCKMETHOD(lock) ((LOCKMETHODID) (lock).tag.locktag_lockmethodid)
---------------------------------------------------------------------------
The lock manager's LOCK objects contain:
LOCK结构体包括:
tag -
    The key fields that are used for hashing locks in the shared memory
    lock hash table.  The contents of the tag essentially define an
    individual lockable object.  See include/storage/lock.h for details
    about the supported types of lockable objects.  This is declared as
    a separate struct to ensure that we always zero out the correct number
    of bytes.  It is critical that any alignment-padding bytes the compiler
    might insert in the struct be zeroed out, else the hash computation
    will be random.  (Currently, we are careful to define struct LOCKTAG
    so that there are no padding bytes.)
tag - 
    该键域用于标记共享内存lock哈希表中的hashing locks.标记tag的内容本质上定义了
    一个独立的可锁定对象.关于已支持的可锁定对象类型的详细信息可参考include/storage/lock.h.
    之所以定义为一个单独的结构是为了确保能够把归零正确的字节数.
    编译器可能插入到结构体中的所有对齐字节数正确被归零是很很重要的,否则的话哈希的计算会是随机的.
    (当前来看,定义结构体LOCKTAG以避免对齐字节)
grantMask -
    This bitmask indicates what types of locks are currently held on the
    given lockable object.  It is used (against the lock table's conflict
    table) to determine if a new lock request will conflict with existing
    lock types held.  Conflicts are determined by bitwise AND operations
    between the grantMask and the conflict table entry for the requested
    lock type.  Bit i of grantMask is 1 if and only if granted[i] > 0.
grantMask -
    该bitmask表示在给定的可锁定对象上持有了哪些类型的locks.
    该字段用于确定新申请的锁是否会与现存的锁存在冲突.
    冲突通过grantMask和请求锁类型的冲突表条目的bitwise AND操作实现.
    当且仅当granted[i] > 0,grantMask的第i位为1.
waitMask -
    This bitmask shows the types of locks being waited for.  Bit i of waitMask
    is 1 if and only if requested[i] > granted[i].
waitMask -
    该字段标记了正在等待的锁类型.当且仅当requested[i] > granted[i],waitMask中的第1位为1.
procLocks -
    This is a shared memory queue of all the PROCLOCK structs associated with
    the lock object.  Note that both granted and waiting PROCLOCKs are in this
    list (indeed, the same PROCLOCK might have some already-granted locks and
    be waiting for more!).
procLocks -
    与lock object相关的PROCLOCK结构体在共享内存中的队列.
    注意链表中存在granted和waiting PROCLOCKs.
    (实际上,同一个PROCLOCK可能有已授予的locks但正在等待更多的锁)    
waitProcs -
    This is a shared memory queue of all PGPROC structures corresponding to
    backends that are waiting (sleeping) until another backend releases this
    lock.  The process structure holds the information needed to determine
    if it should be woken up when the lock is released.
waitProcs -
    对应等待其他后台进程释放锁的后台进程的PGPROC结构体在共享内存中的队列.
    进程结构体保存了用于确定在锁释放时是否需要唤醒的相关信息.
nRequested -
    Keeps a count of how many times this lock has been attempted to be
    acquired.  The count includes attempts by processes which were put
    to sleep due to conflicts.  It also counts the same backend twice
    if, for example, a backend process first acquires a read and then
    acquires a write.  (But multiple acquisitions of the same lock/lock mode
    within a backend are not multiply counted here; they are recorded
    only in the backend's LOCALLOCK structure.)
nRequested -
    该字段保存了尝试获取该锁的次数.计数包括因为冲突而处于休眠状态的次数.
    如果一个进程第一次请求读然后请求写时可能会导致该进程被多次统计.    
requested -
    Keeps a count of how many locks of each type have been attempted.  Only
    elements 1 through MAX_LOCKMODES-1 are used as they correspond to the lock
    type defined constants.  Summing the values of requested[] should come out
    equal to nRequested.
requested -
    该字段保存了尝试获取多少种锁类型.只有1 -> MAX_LOCKMODES-1被使用,因为这对应了锁类型常量.
    计算requested数组的和应等于nRequested.    
nGranted -
    Keeps count of how many times this lock has been successfully acquired.
    This count does not include attempts that are waiting due to conflicts.
    Otherwise the counting rules are the same as for nRequested.
nGranted -
    成功获取该锁的次数.该计数不包括因为冲突而等待的次数.因此该计数规则与nRequested一样.
granted -
    Keeps count of how many locks of each type are currently held.  Once again
    only elements 1 through MAX_LOCKMODES-1 are used (0 is not).  Also, like
    requested[], summing the values of granted[] should total to the value
    of nGranted.
granted -
    保存每种类型有多少锁.1 -> MAX_LOCKMODES-1是有用的.
    与requested类似,granted[]数组的和应等于nGranted.
We should always have 0 <= nGranted <= nRequested, and
0 <= granted[i] <= requested[i] for each i.  When all the request counts
go to zero, the LOCK object is no longer needed and can be freed.
nGranted的的范围为[0,nRequested],对于每一个granted[i]范围为[0,requested[i]].
如果所有请求变为0,那么LOCK对象不再需要,会通过free释放.

到此,相信大家对“PostgreSQL Locks中LOCK结构体是什么”有了更深的了解,不妨来实际操作一番吧!这里是亿速云网站,更多相关内容可以进入相关频道进行查询,关注我们,继续学习!

推荐阅读:
  1. 怎么理解PostgreSQL Locks中的Fast Path Locking
  2. 怎么理解PostgreSQL Locks中的Lock Manager Internal Locking

免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。

postgresql

上一篇:怎么理解oracle等待事件enq

下一篇:sed的基础用法是怎么样的

相关阅读

您好,登录后才能下订单哦!

密码登录
登录注册
其他方式登录
点击 登录注册 即表示同意《亿速云用户服务条款》