Arj*_*kar 373
我把这个答案写下来是因为我认为这将是一个有趣(和适合)的类比:
将可锁定对象想象为包含教师(作家)和许多学生(读者)的教室中的黑板(可锁定).
当老师在板上写东西(独家锁)时:
没有人可以阅读它,因为它仍在被写入,并且她正在阻止你的视图=> 如果一个对象被独占锁定,则无法获得共享锁.
其他老师也不会出现并开始写作,或者董事会变得难以理解,并使学生感到困惑=> 如果一个对象被独占锁定,则无法获得其他独占锁.
当学生正在阅读(共享锁)时,董事会上有什么:
他们都可以一起读取它上面的内容=> 多个共享锁可以共存.
教师在清除电路板写更多信息之前等待他们完成阅读=> 如果已存在一个或多个共享锁,则无法获得独占锁.
Pet*_*one 28
这很简单.读锁也称为共享锁,因为多个进程可以同时读取.读锁定的目的是防止另一个进程获取写锁定.相反,写入锁定在写入操作完成时禁止所有其他操作,这就是为什么它被描述为独占的原因.
所以一个读锁定说"你现在可以阅读,但如果你想写,你必须等待",而写锁则说"你必须等待".
我知道你正在研究支持你的学习,但我无法抗拒讲课的冲动.
无效的锁定使用是导致性能问题的主要原因.使用区分读写锁定的锁定系统是一个良好的开端,但仔细的设计有时可以消除锁定的大部分需求.例如,会话状态永远不应该保存在每个状态元素的一个全局集合中.
我实际上已经看到了这一点.这是一个残暴的设计,导致拳击和对会话状态的每次最后更改的集合的更改,需要一个持久的写锁定.开销正在瘫痪,有效地将服务器减少到单线程行为.
简单地将所有会话状态聚合到一个结构中是一个巨大的改进.对会话状态的更改仅仅改变了会话状态结构的成员值.由于没有其他会话有机会或甚至有机会直接引用会话的状态,因此唯一更新的集合是会话列表.结果,在一个会话期间完全没有锁定,仅在开始和结束时,吞吐量增加了3000倍.
另一种常见的锁定方案是在用户应用程序的线程之间共享的资源.大多数现代框架使用消息而不是锁来解决这个问题.当你"转换到UI线程"时,实际上是在排队一个包含函数指针和一些参数的消息(或者一个委托和一个堆栈帧,具体取决于实现).
互斥锁或写锁为进程提供了对文件的指定部分进行写操作的互斥访问权限。设置写锁定后，没有其他进程可以锁定文件的该部分。
共享或读取锁定禁止任何其他进程在文件的指定部分上请求写入锁定。但是，其他进程可以请求读取锁。
有关更多信息：http : //www.gnu.org/software/libc/manual/html_node/File-Locks.html
| 归档时间： |
|
| 查看次数： |
71122 次 |
| 最近记录： |