微信扫一扫3.3w+
社区成员
讨论二：Lock/latch/spinlock,deadlock
欢迎大家踊跃发言讨论二：Lock/latch/spinlock,deadlock
...全文
当前发帖距今超过3年，不再开放新的回复
发表回复
wangnaisheng 2014-07-31
mark一下，学习~
- 打赏
- 举报
Neo_whl 2014-03-05
惭愧这网站没去过几次，英语得补补了，看起来没那么轻松了！
- 打赏
- 举报
魔者侠心之明星级程序员 2014-03-05
“什么时候该上什么锁是不是数据库服务器自己的机制判断决定的”
基本上是的，但也可以显示的加query hint。
http://technet.microsoft.com/en-us/library/aa213026(v=sql.80).aspx
“那么作为使用者能不能知道服务器作出相关上锁的判断依据呢”
是的，这个是根据事物的隔离级别.
http://technet.microsoft.com/en-us/library/ms189122(v=sql.105).aspx
- 打赏
- 举报
Neo_whl 2014-03-05
什么时候该上什么锁是不是数据库服务器自己的机制判断决定的，那么作为使用者能不能知道服务器作出相关上锁的判断依据呢
- 打赏
- 举报
dfasri 2013-12-13
你所说的就类似于多个资源的访问问题了, 通常, 为了方便, 当然是直接锁定两个表的写入, 然后写完了才开锁, 这样来保持事务完整性, 这个理解是正确的.
我提供的另一种方案是: 其中一个是检测线程, 另外两个是写入表的线程, 检测线无疑就是检测这次操作, 是否一定可以在两个表中写入, 这个是读取操作, 可以并行的, 检测条件成立的操作, 才能够进入写线程, 写线程就是照上述的写完表一, 写表二. 同样是实现无锁并且可以完成操作的.
这种就是所谓的无回滚业务模式, 当然这个回滚的定义, 仅限于在底层实现的细节上, 并不是在业务层上不能够回滚.
上锁, 换句话来说, 就是轮流访问, 轮流访问, 换句话来说就是单一通行, 也就是单线程, 没有任何的锁是不能够换成流水线来处理的. 只是说流水线总是会比上锁要设计复杂而已, 所以不追求最高效率的情况下, 上锁是折衷选择.[/quote]
但是流水线的也会有问题，如果病发量太大的话，会出现要更新数据已经被人抢先更新了。[/quote]
其实流水线只单纯把上锁并行的流程, 变成串行跟并行的小片连接在一起, 实现无锁的处理过程而已.
想想两个表写入, 假如都要花2秒, 那么三个请求的完成时长分别为4秒, 8秒, 12秒.
但把这个流程按小片分开, 那么流水线满了以后, 平均每2秒就完成一个请求了, 即三个请求的完成时间分别为4秒, 6秒, 8秒. 如果真要追求效率, 锁都可以避免的.
- 打赏
- 举报
KevinLiu 2013-12-13
有没有类似的系统？这种系统跟普通的数据库比缺点是什么？跟SQL Server 2014 的OLTP 数据库概念有什么区别？[/quote]
锁有研究, 但数据库是没有研究的, 唯一知道数据库的每条记录都会有锁位, 在修改之前一定会先上锁位再进行更新的, 读取是不需要的.[/quote]
读取也是要锁的，2014的内存数据库就是Lock Free， Latch Free。
- 打赏
- 举报
dfasri 2013-12-13
有没有类似的系统？这种系统跟普通的数据库比缺点是什么？跟SQL Server 2014 的OLTP 数据库概念有什么区别？[/quote]
锁有研究, 但数据库是没有研究的, 唯一知道数据库的每条记录都会有锁位, 在修改之前一定会先上锁位再进行更新的, 读取是不需要的.
- 打赏
- 举报
KevinLiu 2013-12-13
你所说的就类似于多个资源的访问问题了, 通常, 为了方便, 当然是直接锁定两个表的写入, 然后写完了才开锁, 这样来保持事务完整性, 这个理解是正确的.
我提供的另一种方案是: 其中一个是检测线程, 另外两个是写入表的线程, 检测线无疑就是检测这次操作, 是否一定可以在两个表中写入, 这个是读取操作, 可以并行的, 检测条件成立的操作, 才能够进入写线程, 写线程就是照上述的写完表一, 写表二. 同样是实现无锁并且可以完成操作的.
这种就是所谓的无回滚业务模式, 当然这个回滚的定义, 仅限于在底层实现的细节上, 并不是在业务层上不能够回滚.
上锁, 换句话来说, 就是轮流访问, 轮流访问, 换句话来说就是单一通行, 也就是单线程, 没有任何的锁是不能够换成流水线来处理的. 只是说流水线总是会比上锁要设计复杂而已, 所以不追求最高效率的情况下, 上锁是折衷选择.[/quote]
但是流水线的也会有问题，如果病发量太大的话，会出现要更新数据已经被人抢先更新了。[/quote]
其实流水线只单纯把上锁并行的流程, 变成串行跟并行的小片连接在一起, 实现无锁的处理过程而已.
想想两个表写入, 假如都要花2秒, 那么三个请求的完成时长分别为4秒, 8秒, 12秒.
但把这个流程按小片分开, 那么流水线满了以后, 平均每2秒就完成一个请求了, 即三个请求的完成时间分别为4秒, 6秒, 8秒. 如果真要追求效率, 锁都可以避免的.[/quote]
那如果更新的使一条记录呢？[/quote]
一条记录也就是一个表, 在插入的时候就算你不想上锁, 数据库底层还是谁最后更新进去, 就会谁是最后结果, 锁早就在数据库内部做好了...外部还需要上什么锁..[/quote]
有没有类似的系统？这种系统跟普通的数据库比缺点是什么？跟SQL Server 2014 的OLTP 数据库概念有什么区别？
- 打赏
- 举报
dfasri 2013-12-13
你所说的就类似于多个资源的访问问题了, 通常, 为了方便, 当然是直接锁定两个表的写入, 然后写完了才开锁, 这样来保持事务完整性, 这个理解是正确的.
我提供的另一种方案是: 其中一个是检测线程, 另外两个是写入表的线程, 检测线无疑就是检测这次操作, 是否一定可以在两个表中写入, 这个是读取操作, 可以并行的, 检测条件成立的操作, 才能够进入写线程, 写线程就是照上述的写完表一, 写表二. 同样是实现无锁并且可以完成操作的.
这种就是所谓的无回滚业务模式, 当然这个回滚的定义, 仅限于在底层实现的细节上, 并不是在业务层上不能够回滚.
上锁, 换句话来说, 就是轮流访问, 轮流访问, 换句话来说就是单一通行, 也就是单线程, 没有任何的锁是不能够换成流水线来处理的. 只是说流水线总是会比上锁要设计复杂而已, 所以不追求最高效率的情况下, 上锁是折衷选择.[/quote]
但是流水线的也会有问题，如果病发量太大的话，会出现要更新数据已经被人抢先更新了。[/quote]
其实流水线只单纯把上锁并行的流程, 变成串行跟并行的小片连接在一起, 实现无锁的处理过程而已.
想想两个表写入, 假如都要花2秒, 那么三个请求的完成时长分别为4秒, 8秒, 12秒.
但把这个流程按小片分开, 那么流水线满了以后, 平均每2秒就完成一个请求了, 即三个请求的完成时间分别为4秒, 6秒, 8秒. 如果真要追求效率, 锁都可以避免的.[/quote]
那如果更新的使一条记录呢？[/quote]
一条记录也就是一个表, 在插入的时候就算你不想上锁, 数据库底层还是谁最后更新进去, 就会谁是最后结果, 锁早就在数据库内部做好了...外部还需要上什么锁..
- 打赏
- 举报
KevinLiu 2013-12-13
你所说的就类似于多个资源的访问问题了, 通常, 为了方便, 当然是直接锁定两个表的写入, 然后写完了才开锁, 这样来保持事务完整性, 这个理解是正确的.
我提供的另一种方案是: 其中一个是检测线程, 另外两个是写入表的线程, 检测线无疑就是检测这次操作, 是否一定可以在两个表中写入, 这个是读取操作, 可以并行的, 检测条件成立的操作, 才能够进入写线程, 写线程就是照上述的写完表一, 写表二. 同样是实现无锁并且可以完成操作的.
这种就是所谓的无回滚业务模式, 当然这个回滚的定义, 仅限于在底层实现的细节上, 并不是在业务层上不能够回滚.
上锁, 换句话来说, 就是轮流访问, 轮流访问, 换句话来说就是单一通行, 也就是单线程, 没有任何的锁是不能够换成流水线来处理的. 只是说流水线总是会比上锁要设计复杂而已, 所以不追求最高效率的情况下, 上锁是折衷选择.[/quote]
但是流水线的也会有问题，如果病发量太大的话，会出现要更新数据已经被人抢先更新了。[/quote]
其实流水线只单纯把上锁并行的流程, 变成串行跟并行的小片连接在一起, 实现无锁的处理过程而已.
想想两个表写入, 假如都要花2秒, 那么三个请求的完成时长分别为4秒, 8秒, 12秒.
但把这个流程按小片分开, 那么流水线满了以后, 平均每2秒就完成一个请求了, 即三个请求的完成时间分别为4秒, 6秒, 8秒. 如果真要追求效率, 锁都可以避免的.[/quote]
那如果更新的使一条记录呢？
- 打赏
- 举报
cxmcxm 2013-12-12
锁之所以的存在有受软硬件技术约制的影响，但用不用锁，用什么锁，更多是事务处理需求。很多时间，深夜上某些网站，会弹出数据维护中，请什么时候再连接的提示，可广义地理解为这也是一种锁。是必须的，如不锁，可能出来的是一个不可预知的网页。
- 打赏
- 举报
KevinLiu 2013-12-10
你所说的就类似于多个资源的访问问题了, 通常, 为了方便, 当然是直接锁定两个表的写入, 然后写完了才开锁, 这样来保持事务完整性, 这个理解是正确的.
我提供的另一种方案是: 其中一个是检测线程, 另外两个是写入表的线程, 检测线无疑就是检测这次操作, 是否一定可以在两个表中写入, 这个是读取操作, 可以并行的, 检测条件成立的操作, 才能够进入写线程, 写线程就是照上述的写完表一, 写表二. 同样是实现无锁并且可以完成操作的.
这种就是所谓的无回滚业务模式, 当然这个回滚的定义, 仅限于在底层实现的细节上, 并不是在业务层上不能够回滚.
上锁, 换句话来说, 就是轮流访问, 轮流访问, 换句话来说就是单一通行, 也就是单线程, 没有任何的锁是不能够换成流水线来处理的. 只是说流水线总是会比上锁要设计复杂而已, 所以不追求最高效率的情况下, 上锁是折衷选择.[/quote]
但是流水线的也会有问题，如果病发量太大的话，会出现要更新数据已经被人抢先更新了。
- 打赏
- 举报
dfasri 2013-12-09
你所说的就类似于多个资源的访问问题了, 通常, 为了方便, 当然是直接锁定两个表的写入, 然后写完了才开锁, 这样来保持事务完整性, 这个理解是正确的.
我提供的另一种方案是: 其中一个是检测线程, 另外两个是写入表的线程, 检测线无疑就是检测这次操作, 是否一定可以在两个表中写入, 这个是读取操作, 可以并行的, 检测条件成立的操作, 才能够进入写线程, 写线程就是照上述的写完表一, 写表二. 同样是实现无锁并且可以完成操作的.
这种就是所谓的无回滚业务模式, 当然这个回滚的定义, 仅限于在底层实现的细节上, 并不是在业务层上不能够回滚.
上锁, 换句话来说, 就是轮流访问, 轮流访问, 换句话来说就是单一通行, 也就是单线程, 没有任何的锁是不能够换成流水线来处理的. 只是说流水线总是会比上锁要设计复杂而已, 所以不追求最高效率的情况下, 上锁是折衷选择.
- 打赏
- 举报
LF11110000 2013-12-09
好主题，值得研究！
- 打赏
- 举报
cxmcxm 2013-12-09
锁是用来保证事务完整性的，并不单单是读写操作。
比如入库操作，最简单的，必须更新两个表
入库记录表与库存表，两个表一起更新后，提交事务，成功后锁才会释放
入库记录可能很快，更新库存可能很慢，但在提交事务前，update的记录会一直被锁住。
保证数据不会被别的用户修改。
- 打赏
- 举报
dfasri 2013-12-06
现在都什么年代了, 都是一台机器有N个CPU的, 在这种类似无限的资源环境下, 只要做好流水线的设计, 根本就不需要用到LOCK.
读取这种操作本身是可以并行的
但作为策略来说, 绝大部分的情况下, 没有必须要做到只要一删除就不能够被读取, 通常这种删除跟读取的并行之间都允许存在时间差的, 也就是在读取某个点的过程中, 这个点即使被删除了, 这个点还是在这次读取中有效的.
作为写入操作, 很明显就是不能够并行写的, 也就是写操作通常为单一通行的模式, 一次只允许一个操作, 这种情况下, 用流水线把这些单一的操作综合起来的话, 处理速度会快很多, 上锁的时间根本就不需要花费了, 怀疑这种上锁的时间已经足够处理完成一个请求了, 所以上锁都是很浪费资源的.
上面说到的例子, 大概使用的就是这种方式, 把不能够并行的变成串行, 并且使串行不影响并行的处理, 这种就是最快的. 上锁都是在流水线设计上偷懒而得出的折中方案.
- 打赏
- 举报
seusoftware 2013-12-05
lock,是用来控制事务一致性的，也就是对数据库对象的访问，有不同力度，row, page, extent, table, db...
latch,是用来控制内存一致性的，数据/日志被cache在内存，不同用户需要修改时，也是要有先后的
spinlock,是sql server的一个优化机制，不管是lock/latch，如果排队了，当前请求就排队了，等到lock/latch资源释放了再来工作，这里面有个context switch的过程，spinlock起的作用就是在排队等待前观望(spinloop)一小段时间，如果资源释放了，就直接工作了，省去了context switch的成本消耗；
deadlock,就是lock了，不同会话间的lock互相等待了，sql server会选择kill一个成本较低的会话；
- 打赏
- 举报
ChinaITOldMan 2013-12-05
好主题，值得研究！
- 打赏
- 举报
lhw7791086 2013-12-05
- 打赏
- 举报
isince1985 2013-12-05
厉害 ，好东西
- 打赏
- 举报
加载更多回复（26）