资讯

精准传达 • 有效沟通

从品牌网站建设到网络营销策划,从策略到执行的一站式服务

PostgreSQL源码解读(221)-Locks(PROCLOCKStruct)

本节是PostgreSQL Locks中介绍PROCLOCK结构体部分,翻译自README文件.

专注于为中小企业提供成都做网站、成都网站设计服务,电脑端+手机端+微信端的三站合一,更高效的管理,为中小企业天全免费做网站提供优质的服务。我们立足成都,凝聚了一批互联网行业人才,有力地推动了1000+企业的稳健成长,帮助中小企业通过网站建设实现规模扩充和转变。

一、PROCLOCK Struct


/*
 * We may have several different backends holding or awaiting locks
 * on the same lockable object.  We need to store some per-holder/waiter
 * information for each such holder (or would-be holder).  This is kept in
 * a PROCLOCK struct.
 *
 * PROCLOCKTAG is the key information needed to look up a PROCLOCK item in the
 * proclock hashtable.  A PROCLOCKTAG value uniquely identifies the combination
 * of a lockable object and a holder/waiter for that object.  (We can use
 * pointers here because the PROCLOCKTAG need only be unique for the lifespan
 * of the PROCLOCK, and it will never outlive the lock or the proc.)
 *
 * Internally to a backend, it is possible for the same lock to be held
 * for different purposes: the backend tracks transaction locks separately
 * from session locks.  However, this is not reflected in the shared-memory
 * state: we only track which backend(s) hold the lock.  This is OK since a
 * backend can never block itself.
 *
 * The holdMask field shows the already-granted locks represented by this
 * proclock.  Note that there will be a proclock object, possibly with
 * zero holdMask, for any lock that the process is currently waiting on.
 * Otherwise, proclock objects whose holdMasks are zero are recycled
 * as soon as convenient.
 *
 * releaseMask is workspace for LockReleaseAll(): it shows the locks due
 * to be released during the current call.  This must only be examined or
 * set by the backend owning the PROCLOCK.
 *
 * Each PROCLOCK object is linked into lists for both the associated LOCK
 * object and the owning PGPROC object.  Note that the PROCLOCK is entered
 * into these lists as soon as it is created, even if no lock has yet been
 * granted.  A PGPROC that is waiting for a lock to be granted will also be
 * linked into the lock's waitProcs queue.
 */
typedef struct PROCLOCKTAG
{
    /* NB: we assume this struct contains no padding! */
    LOCK       *myLock;         /* link to per-lockable-object information */
    PGPROC     *myProc;         /* link to PGPROC of owning backend */
} PROCLOCKTAG;
typedef struct PROCLOCK
{
    /* tag */
    PROCLOCKTAG tag;            /* unique identifier of proclock object */
    /* data */
    PGPROC     *groupLeader;    /* proc's lock group leader, or proc itself */
    LOCKMASK    holdMask;       /* bitmask for lock types currently held */
    LOCKMASK    releaseMask;    /* bitmask for lock types to be released */
    SHM_QUEUE   lockLink;       /* list link in LOCK's list of proclocks */
    SHM_QUEUE   procLink;       /* list link in PGPROC's list of proclocks */
} PROCLOCK;
#define PROCLOCK_LOCKMETHOD(proclock) \
    LOCK_LOCKMETHOD(*((proclock).tag.myLock))
---------------------------------------------------------------------------
The lock manager's PROCLOCK objects contain:
tag -
    The key fields that are used for hashing entries in the shared memory
    PROCLOCK hash table.  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 PROCLOCKTAG so that there are no padding bytes.)
    tag.myLock
        Pointer to the shared LOCK object this PROCLOCK is for.
    tag.myProc
        Pointer to the PGPROC of backend process that owns this PROCLOCK.
    Note: it's OK to use pointers here because a PROCLOCK never outlives
    either its lock or its proc.  The tag is therefore unique for as long
    as it needs to be, even though the same tag values might mean something
    else at other times.
tag -
    与LOCK结构体中的tag字段类似,用于标识共享内存中的PROCLOCK哈希表中对应的条目.
    tag.mylock
        指向PROCLOCK所表示的共享LOCK对象的指针
    tag.myProc
        指向持有该PROCLOCK的PGPROC后台进程
holdMask -
    A bitmask for the lock modes successfully acquired by this PROCLOCK.
    This should be a subset of the LOCK object's grantMask, and also a
    subset of the PGPROC object's heldLocks mask (if the PGPROC is
    currently waiting for another lock mode on this lock).
holdMask -
    该PROCLOCK请求获得的lock模式位掩码.
    应为LOCK's grantMask掩码的子集,同时也是PGPROC's heldlocks掩码的子集.
releaseMask -
    A bitmask for the lock modes due to be released during LockReleaseAll.
    This must be a subset of the holdMask.  Note that it is modified without
    taking the partition LWLock, and therefore it is unsafe for any
    backend except the one owning the PROCLOCK to examine/change it.
releaseMask -
    在LockReleaseAll执行过程中即将被释放的lock模式位掩码.
    应为holdMask位掩码的子集.注意更新该值时不需要持有分区LWLock,因此除了自身的PROCLOCK外
    其他后台进程是不安全的.
lockLink -
    List link for shared memory queue of all the PROCLOCK objects for the
    same LOCK.
lockLink -
    共享内存中同一个LOCK的PROCLOCK对象队列链表链接.
procLink -
    List link for shared memory queue of all the PROCLOCK objects for the
    same backend.
procLink -
    共享内存中同一个后台进程所有PROCLOCK对象的的链表链接.

二、参考资料

README


分享题目:PostgreSQL源码解读(221)-Locks(PROCLOCKStruct)
新闻来源:http://cdkjz.cn/article/iisgdi.html
多年建站经验

多一份参考,总有益处

联系快上网,免费获得专属《策划方案》及报价

咨询相关问题或预约面谈,可以通过以下方式与我们联系

大客户专线   成都:13518219792   座机:028-86922220