数据结构
涉及到的和锁相关的数据结构主要是如下几个:
MDL_context:字典锁上下文。包含一个事物所有的字典锁请求。
MDL_request:字典锁请求。包含对某个对象的某种锁的请求。
MDL_ticket:字典锁排队。MDL_request就是为了获取一个ticket。
MDL_lock:锁资源。一个对象全局唯一。可以允许多个可以并发的事物同时获得。
涉及到的源码文件主要是sql/mdl.cc
锁资源
锁资源在系统中是共享的,即全局的,存放在static MDL_map mdl_locks;的hash链表中,对于数据库中的一个对象,其hashkey必然是唯一的,对应一个锁资源。多个事务同时对一张表操作时,申请的 lock也是同一个内存对象。获取mdl_locks中的lock需要通过全局互斥量保护起来 mysql_mutex_lock(&m_mutex); m_mutex是MDL_map的成员。
上锁流程
一个会话连接在实现中对应一个THD实体,一个THD对应一个MDL_CONTEXT,表示需要的mdl锁资源,一个MDL_CONTEXT中包含多个MDL_REQUEST,一个MDL_REQUEST即是对一个对象的某种类型的lock请求。每个mdl_request上有一个ticket对象,ticket中包含lock。
上锁的也就是根据MDL_REQUEST进行上锁。
Acquire_lock:
if (mdl_requestcontainsthe needed ticket )
returnticket;
Endif;
Createa ticket;
If (!find lockinlock_sys)
Createa lock;
Endif
If (lock can be grantedtomdl_request)
Setlocktoticket;
Settickettomdl_request;
Else
Waitforlock
Endif
稍微解释下,首先是在mdl_request本身去查看有没有相等的或者stronger的ticket,如果存在,则直接使用。否则创建一个 ticket,查找上锁对象对应的lock,没有则创建。检查lock是否可以被赋给本事务,如果可以直接返回,否则等待这个lock;
锁等待与唤醒
字典对象的锁等待是发生在两个事物对同一对象上不兼容的锁导致的。当然,由于lock的唯一性,先到先得,后到的只能等待。
如何判断一个lock是否可以grant给一个TX?这需要结合lock结构来看了,lock上有两个成员,grant和wait,grant代表此 lock允许的事物都上了哪些锁,wait表示等待的事务需要上哪些锁。其判断一个事物是否可以grant的逻辑如下:
If(compatible(lock.grant, tx.locktype))
If (compatible(lock.wait, tx.locktype))
returncan_grant;
Endif
Endif
32/3<123>