继两年前的上一篇文章之后，不靠谱博主终于想起了How does it work这个坑。主要是近期也没有遇到可值得分享的「精巧」的实现。之前其实也过了一遍threading模块的源码，对里面的各种锁也只是有个大概印象，并且它们之前非常像，很容易让人 confusing。这次碰到实际需要，于是仔细看了一下源码，发现还是有很多搞头的。当然，你只是使用的话照着例子用就好了不会出错，但还是值得花点工夫弄清里面的原理。
Condition 的使用示例
下面是我随便从网上搜来的代码片段
import threading, time
class Hider(threading.Thread):
def __init__(self, cond, name):
super(Hider, self).__init__()
self.cond = cond
self.name = name
def run(self):
time.sleep(1) #确保先运行Seeker中的方法
self.cond.acquire() #b
print self.name + ': 我已经把眼睛蒙上了'
self.cond.notify()
self.cond.wait() #c
#f
print self.name + ': 我找到你了 ~_~'
self.cond.notify()
self.cond.release()
#g
print self.name + ': 我赢了' #h
class Seeker(threading.Thread):
def __init__(self, cond, name):
super(Seeker, self).__init__()
self.cond = cond
self.name = name
def run(self):
self.cond.acquire()
self.cond.wait() #a #释放对琐的占用，同时线程挂起在这里，直到被notify并重新占有琐。
#d
print self.name + ': 我已经藏好了，你快来找我吧'
self.cond.notify()
self.cond.wait() #e
#h
self.cond.release()
print self.name + ': 被你找到了，哎~~~'
cond = threading.Condition()
seeker = Seeker(cond, 'seeker')
hider = Hider(cond, 'hider')
seeker.start()
hider.start()这里用的捉迷藏，换成聊天也可以。其实就是两个线程间的同步，一应一答。一个线程执行完操作以后通知另一方并等待应答。下面我们要解决一些问题：
- 它跟
Lock有什么区别？ - 可以注意到双方动作前都
acquire了同一个Condition，这样不阻塞吗？ - 为什么一定要
acquire？我换成获取一个普通的Lock行吗？
Condition 源码分析
Condition的初始化方法为Condition(lock)，其中lock不传的话默认是一个RLock()，即可重入锁，关于锁的区别比较好理解，这里就不啰嗦了。初始完之后会把传入的锁存为属性，然后Condition的acquire和release就只是对这个锁的获取释放而已。所以：
lock = Lock()
cond = Condition(lock)
cond.acquire()
# 换成lock.acquire()完全等价，release类似到此为止还看不出为何要用Condition而不用Lock，关键是下面两个方法wait和notify，我把代码完整贴出附上自己的注释：
def wait(self, timeout=None):
if not self._is_owned(): # 必须先获取self._lock
raise RuntimeError("cannot wait on un-acquired lock")
waiter = _allocate_lock() # 新建一个锁
waiter.acquire() # 获取刚刚新建的锁
self._waiters.append(waiter) # 加入waiters列表
saved_state = self._release_save() # 这里释放了self._lock
gotit = False
try: # restore state no matter what (e.g., KeyboardInterrupt)
if timeout is None:
waiter.acquire() # 再次获取新建的锁
gotit = True
else:
if timeout > 0:
gotit = waiter.acquire(True, timeout) # 等待时间后返回
else:
gotit = waiter.acquire(False) # timeout == 0, 立即返回
return gotit
finally:
self._acquire_restore(saved_state) # 重新恢复self._lock状态
if not gotit: # 如果是非阻塞的(timeout != None)
try:
self._waiters.remove(waiter) # 从waiters列表删除
except ValueError:
pass果然 talk is cheap, show me the code，看了代码就一目了然了。可以看到self._lock（就是初始化时传入的那个锁）在第 7 行之前是占用状态的，此时其他线程不可插入，然后整个 try-block 里self._lock是释放状态可被其他线程获取。通过再次获取同一个 waiter 锁达到了阻塞的效果，这样看起来就像是新加入了一个等待者在等待某个事件。等待的这个事件，就是其他线程用同一个Condition实例调用的notify方法：
def notify(self, n=1):
if not self._is_owned():
raise RuntimeError("cannot notify on un-acquired lock")
all_waiters = self._waiters # 获取所有等待的锁
waiters_to_notify = _deque(_islice(all_waiters, n)) # 只选给定数量的等待者，如果是notify_all方法则是全部
if not waiters_to_notify:
return
for waiter in waiters_to_notify:
waiter.release() #
try:
all_waiters.remove(waiter)
except ValueError:
pass可以看到notify方法全程都拥有锁self._lock，这样保证了只有 Notify 完成之后对方才能下一步动作。调用时序如下： 
总结来说的话，就是只有wait()方法能主动释放锁，而notify()不能，所以 waiter 线程一定要先启动，防止发生死锁。
Event 与 Condition
threading中还有一个Event，与Condition非常类似。区别在于前者等待、监听某个值is_set()为真，而后者只是一个通知等待的模型。并且Event中监听值翻转以后，正是通过Condition去通知等待者的。Event变成set以后，就「失效」了，要手动clear一次才能继续使用用，而Condition是可以无限wait, notify循环的。
class Event:
def set(self):
with self._cond:
self._flag = True
self._cond.notify_all()其实，Condition也包含一个wait_for(eval_function, timeout)方法，用来等待某函数的返回值为真。这个方法用起来和Event的作用是很像的，你可以理解为Event只是提供了一个包装好了的Condition。