讨论二:Lock/latch/spinlock,deadlock

开着拖拉机泡妞 2013-12-02 01:04:55
加精
欢迎大家踊跃发言

讨论二:Lock/latch/spinlock,deadlock
...全文
2536 50 打赏 收藏 转发到动态 举报
AI 作业
写回复
用AI写文章
50 条回复
切换为时间正序
请发表友善的回复…
发表回复
wangnaisheng 2014-07-31
  • 打赏
  • 举报
回复
mark一下,学习~
Neo_whl 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
惭愧这网站没去过几次,英语得补补了,看起来没那么轻松了!
  • 打赏
  • 举报
回复
引用 47 楼 u011015550 的回复:
什么时候该上什么锁是不是数据库服务器自己的机制判断决定的,那么作为使用者能不能知道服务器作出相关上锁的判断依据呢
“什么时候该上什么锁是不是数据库服务器自己的机制判断决定的” 基本上是的,但也可以显示的加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
  • 打赏
  • 举报
回复
引用 38 楼 SmithLiu328 的回复:
[quote=引用 36 楼 dfasri 的回复:] [quote=引用 35 楼 cxmcxm 的回复:] 锁是用来保证事务完整性的,并不单单是读写操作。 比如入库操作,最简单的,必须更新两个表 入库记录表与库存表,两个表一起更新后,提交事务,成功后锁才会释放 入库记录可能很快,更新库存可能很慢,但在提交事务前,update的记录会一直被锁住。 保证数据不会被别的用户修改。
你所说的就类似于多个资源的访问问题了, 通常, 为了方便, 当然是直接锁定两个表的写入, 然后写完了才开锁, 这样来保持事务完整性, 这个理解是正确的. 我提供的另一种方案是: 其中一个是检测线程, 另外两个是写入表的线程, 检测线无疑就是检测这次操作, 是否一定可以在两个表中写入, 这个是读取操作, 可以并行的, 检测条件成立的操作, 才能够进入写线程, 写线程就是照上述的写完表一, 写表二. 同样是实现无锁并且可以完成操作的. 这种就是所谓的无回滚业务模式, 当然这个回滚的定义, 仅限于在底层实现的细节上, 并不是在业务层上不能够回滚. 上锁, 换句话来说, 就是轮流访问, 轮流访问, 换句话来说就是单一通行, 也就是单线程, 没有任何的锁是不能够换成流水线来处理的. 只是说流水线总是会比上锁要设计复杂而已, 所以不追求最高效率的情况下, 上锁是折衷选择.[/quote] 但是流水线的也会有问题,如果病发量太大的话,会出现要更新数据已经被人抢先更新了。[/quote] 其实流水线只单纯把上锁并行的流程, 变成串行跟并行的小片连接在一起, 实现无锁的处理过程而已. 想想两个表写入, 假如都要花2秒, 那么三个请求的完成时长分别为4秒, 8秒, 12秒. 但把这个流程按小片分开, 那么流水线满了以后, 平均每2秒就完成一个请求了, 即三个请求的完成时间分别为4秒, 6秒, 8秒. 如果真要追求效率, 锁都可以避免的.
KevinLiu 2013-12-13
  • 打赏
  • 举报
回复
引用 45 楼 dfasri 的回复:
[quote=引用 44 楼 SmithLiu328 的回复:] [quote=引用 43 楼 dfasri 的回复:] 一条记录也就是一个表, 在插入的时候就算你不想上锁, 数据库底层还是谁最后更新进去, 就会谁是最后结果, 锁早就在数据库内部做好了...外部还需要上什么锁..
有没有类似的系统?这种系统跟普通的数据库比缺点是什么?跟SQL Server 2014 的OLTP 数据库概念有什么区别?[/quote] 锁有研究, 但数据库是没有研究的, 唯一知道数据库的每条记录都会有锁位, 在修改之前一定会先上锁位再进行更新的, 读取是不需要的.[/quote] 读取也是要锁的,2014的内存数据库就是Lock Free, Latch Free。
dfasri 2013-12-13
  • 打赏
  • 举报
回复
引用 44 楼 SmithLiu328 的回复:
[quote=引用 43 楼 dfasri 的回复:] 一条记录也就是一个表, 在插入的时候就算你不想上锁, 数据库底层还是谁最后更新进去, 就会谁是最后结果, 锁早就在数据库内部做好了...外部还需要上什么锁..
有没有类似的系统?这种系统跟普通的数据库比缺点是什么?跟SQL Server 2014 的OLTP 数据库概念有什么区别?[/quote] 锁有研究, 但数据库是没有研究的, 唯一知道数据库的每条记录都会有锁位, 在修改之前一定会先上锁位再进行更新的, 读取是不需要的.
KevinLiu 2013-12-13
  • 打赏
  • 举报
回复
引用 43 楼 dfasri 的回复:
[quote=引用 42 楼 SmithLiu328 的回复:] [quote=引用 41 楼 dfasri 的回复:] [quote=引用 38 楼 SmithLiu328 的回复:] [quote=引用 36 楼 dfasri 的回复:] [quote=引用 35 楼 cxmcxm 的回复:] 锁是用来保证事务完整性的,并不单单是读写操作。 比如入库操作,最简单的,必须更新两个表 入库记录表与库存表,两个表一起更新后,提交事务,成功后锁才会释放 入库记录可能很快,更新库存可能很慢,但在提交事务前,update的记录会一直被锁住。 保证数据不会被别的用户修改。
你所说的就类似于多个资源的访问问题了, 通常, 为了方便, 当然是直接锁定两个表的写入, 然后写完了才开锁, 这样来保持事务完整性, 这个理解是正确的. 我提供的另一种方案是: 其中一个是检测线程, 另外两个是写入表的线程, 检测线无疑就是检测这次操作, 是否一定可以在两个表中写入, 这个是读取操作, 可以并行的, 检测条件成立的操作, 才能够进入写线程, 写线程就是照上述的写完表一, 写表二. 同样是实现无锁并且可以完成操作的. 这种就是所谓的无回滚业务模式, 当然这个回滚的定义, 仅限于在底层实现的细节上, 并不是在业务层上不能够回滚. 上锁, 换句话来说, 就是轮流访问, 轮流访问, 换句话来说就是单一通行, 也就是单线程, 没有任何的锁是不能够换成流水线来处理的. 只是说流水线总是会比上锁要设计复杂而已, 所以不追求最高效率的情况下, 上锁是折衷选择.[/quote] 但是流水线的也会有问题,如果病发量太大的话,会出现要更新数据已经被人抢先更新了。[/quote] 其实流水线只单纯把上锁并行的流程, 变成串行跟并行的小片连接在一起, 实现无锁的处理过程而已. 想想两个表写入, 假如都要花2秒, 那么三个请求的完成时长分别为4秒, 8秒, 12秒. 但把这个流程按小片分开, 那么流水线满了以后, 平均每2秒就完成一个请求了, 即三个请求的完成时间分别为4秒, 6秒, 8秒. 如果真要追求效率, 锁都可以避免的.[/quote] 那如果更新的使一条记录呢?[/quote] 一条记录也就是一个表, 在插入的时候就算你不想上锁, 数据库底层还是谁最后更新进去, 就会谁是最后结果, 锁早就在数据库内部做好了...外部还需要上什么锁..[/quote] 有没有类似的系统?这种系统跟普通的数据库比缺点是什么?跟SQL Server 2014 的OLTP 数据库概念有什么区别?
dfasri 2013-12-13
  • 打赏
  • 举报
回复
引用 42 楼 SmithLiu328 的回复:
[quote=引用 41 楼 dfasri 的回复:] [quote=引用 38 楼 SmithLiu328 的回复:] [quote=引用 36 楼 dfasri 的回复:] [quote=引用 35 楼 cxmcxm 的回复:] 锁是用来保证事务完整性的,并不单单是读写操作。 比如入库操作,最简单的,必须更新两个表 入库记录表与库存表,两个表一起更新后,提交事务,成功后锁才会释放 入库记录可能很快,更新库存可能很慢,但在提交事务前,update的记录会一直被锁住。 保证数据不会被别的用户修改。
你所说的就类似于多个资源的访问问题了, 通常, 为了方便, 当然是直接锁定两个表的写入, 然后写完了才开锁, 这样来保持事务完整性, 这个理解是正确的. 我提供的另一种方案是: 其中一个是检测线程, 另外两个是写入表的线程, 检测线无疑就是检测这次操作, 是否一定可以在两个表中写入, 这个是读取操作, 可以并行的, 检测条件成立的操作, 才能够进入写线程, 写线程就是照上述的写完表一, 写表二. 同样是实现无锁并且可以完成操作的. 这种就是所谓的无回滚业务模式, 当然这个回滚的定义, 仅限于在底层实现的细节上, 并不是在业务层上不能够回滚. 上锁, 换句话来说, 就是轮流访问, 轮流访问, 换句话来说就是单一通行, 也就是单线程, 没有任何的锁是不能够换成流水线来处理的. 只是说流水线总是会比上锁要设计复杂而已, 所以不追求最高效率的情况下, 上锁是折衷选择.[/quote] 但是流水线的也会有问题,如果病发量太大的话,会出现要更新数据已经被人抢先更新了。[/quote] 其实流水线只单纯把上锁并行的流程, 变成串行跟并行的小片连接在一起, 实现无锁的处理过程而已. 想想两个表写入, 假如都要花2秒, 那么三个请求的完成时长分别为4秒, 8秒, 12秒. 但把这个流程按小片分开, 那么流水线满了以后, 平均每2秒就完成一个请求了, 即三个请求的完成时间分别为4秒, 6秒, 8秒. 如果真要追求效率, 锁都可以避免的.[/quote] 那如果更新的使一条记录呢?[/quote] 一条记录也就是一个表, 在插入的时候就算你不想上锁, 数据库底层还是谁最后更新进去, 就会谁是最后结果, 锁早就在数据库内部做好了...外部还需要上什么锁..
KevinLiu 2013-12-13
  • 打赏
  • 举报
回复
引用 41 楼 dfasri 的回复:
[quote=引用 38 楼 SmithLiu328 的回复:] [quote=引用 36 楼 dfasri 的回复:] [quote=引用 35 楼 cxmcxm 的回复:] 锁是用来保证事务完整性的,并不单单是读写操作。 比如入库操作,最简单的,必须更新两个表 入库记录表与库存表,两个表一起更新后,提交事务,成功后锁才会释放 入库记录可能很快,更新库存可能很慢,但在提交事务前,update的记录会一直被锁住。 保证数据不会被别的用户修改。
你所说的就类似于多个资源的访问问题了, 通常, 为了方便, 当然是直接锁定两个表的写入, 然后写完了才开锁, 这样来保持事务完整性, 这个理解是正确的. 我提供的另一种方案是: 其中一个是检测线程, 另外两个是写入表的线程, 检测线无疑就是检测这次操作, 是否一定可以在两个表中写入, 这个是读取操作, 可以并行的, 检测条件成立的操作, 才能够进入写线程, 写线程就是照上述的写完表一, 写表二. 同样是实现无锁并且可以完成操作的. 这种就是所谓的无回滚业务模式, 当然这个回滚的定义, 仅限于在底层实现的细节上, 并不是在业务层上不能够回滚. 上锁, 换句话来说, 就是轮流访问, 轮流访问, 换句话来说就是单一通行, 也就是单线程, 没有任何的锁是不能够换成流水线来处理的. 只是说流水线总是会比上锁要设计复杂而已, 所以不追求最高效率的情况下, 上锁是折衷选择.[/quote] 但是流水线的也会有问题,如果病发量太大的话,会出现要更新数据已经被人抢先更新了。[/quote] 其实流水线只单纯把上锁并行的流程, 变成串行跟并行的小片连接在一起, 实现无锁的处理过程而已. 想想两个表写入, 假如都要花2秒, 那么三个请求的完成时长分别为4秒, 8秒, 12秒. 但把这个流程按小片分开, 那么流水线满了以后, 平均每2秒就完成一个请求了, 即三个请求的完成时间分别为4秒, 6秒, 8秒. 如果真要追求效率, 锁都可以避免的.[/quote] 那如果更新的使一条记录呢?
cxmcxm 2013-12-12
  • 打赏
  • 举报
回复
锁之所以的存在有受软硬件技术约制的影响,但用不用锁,用什么锁,更多是事务处理需求。很多时间,深夜上某些网站,会弹出数据维护中,请什么时候再连接的提示,可广义地理解为这也是一种锁。是必须的,如不锁,可能出来的是一个不可预知的网页。
KevinLiu 2013-12-10
  • 打赏
  • 举报
回复
引用 36 楼 dfasri 的回复:
[quote=引用 35 楼 cxmcxm 的回复:] 锁是用来保证事务完整性的,并不单单是读写操作。 比如入库操作,最简单的,必须更新两个表 入库记录表与库存表,两个表一起更新后,提交事务,成功后锁才会释放 入库记录可能很快,更新库存可能很慢,但在提交事务前,update的记录会一直被锁住。 保证数据不会被别的用户修改。
你所说的就类似于多个资源的访问问题了, 通常, 为了方便, 当然是直接锁定两个表的写入, 然后写完了才开锁, 这样来保持事务完整性, 这个理解是正确的. 我提供的另一种方案是: 其中一个是检测线程, 另外两个是写入表的线程, 检测线无疑就是检测这次操作, 是否一定可以在两个表中写入, 这个是读取操作, 可以并行的, 检测条件成立的操作, 才能够进入写线程, 写线程就是照上述的写完表一, 写表二. 同样是实现无锁并且可以完成操作的. 这种就是所谓的无回滚业务模式, 当然这个回滚的定义, 仅限于在底层实现的细节上, 并不是在业务层上不能够回滚. 上锁, 换句话来说, 就是轮流访问, 轮流访问, 换句话来说就是单一通行, 也就是单线程, 没有任何的锁是不能够换成流水线来处理的. 只是说流水线总是会比上锁要设计复杂而已, 所以不追求最高效率的情况下, 上锁是折衷选择.[/quote] 但是流水线的也会有问题,如果病发量太大的话,会出现要更新数据已经被人抢先更新了。
dfasri 2013-12-09
  • 打赏
  • 举报
回复
引用 35 楼 cxmcxm 的回复:
锁是用来保证事务完整性的,并不单单是读写操作。 比如入库操作,最简单的,必须更新两个表 入库记录表与库存表,两个表一起更新后,提交事务,成功后锁才会释放 入库记录可能很快,更新库存可能很慢,但在提交事务前,update的记录会一直被锁住。 保证数据不会被别的用户修改。
你所说的就类似于多个资源的访问问题了, 通常, 为了方便, 当然是直接锁定两个表的写入, 然后写完了才开锁, 这样来保持事务完整性, 这个理解是正确的. 我提供的另一种方案是: 其中一个是检测线程, 另外两个是写入表的线程, 检测线无疑就是检测这次操作, 是否一定可以在两个表中写入, 这个是读取操作, 可以并行的, 检测条件成立的操作, 才能够进入写线程, 写线程就是照上述的写完表一, 写表二. 同样是实现无锁并且可以完成操作的. 这种就是所谓的无回滚业务模式, 当然这个回滚的定义, 仅限于在底层实现的细节上, 并不是在业务层上不能够回滚. 上锁, 换句话来说, 就是轮流访问, 轮流访问, 换句话来说就是单一通行, 也就是单线程, 没有任何的锁是不能够换成流水线来处理的. 只是说流水线总是会比上锁要设计复杂而已, 所以不追求最高效率的情况下, 上锁是折衷选择.
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)

34,838

社区成员

发帖
与我相关
我的任务
社区描述
MS-SQL Server相关内容讨论专区
社区管理员
  • 基础类社区
  • 二月十六
  • 卖水果的net
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧