在redis中更新变量的无竞争条件的方法是:
r = redis.Redis()
with r.pipeline() as p:
while 1:
try:
p.watch(KEY)
val = p.get(KEY)
newval = int(val) + 42
p.multi()
p.set(KEY, newval)
p.execute() # raises WatchError if anyone else changed KEY
break
except redis.WatchError:
continue # retry
这比直接版本(包含竞争条件)要复杂得多:
r = redis.Redis()
val = r.get(KEY)
newval = int(val) + 42
r.set(KEY, newval)
所以我认为上下文管理器会让这更容易使用,但是,我遇到了问题......
我最初的想法是
with update(KEY) as val:
newval = val + 42
somehow return newval to the contextmanager...?
没有明显的方法来做最后一行,所以我尝试了::
@contextmanager
def update(key, cn=None):
"""Usage::
with update(KEY) as (p, val):
newval = int(val) + 42
p.set(KEY, newval)
"""
r = cn or redis.Redis()
with r.pipeline() as p:
while 1:
try:
p.watch(key) # --> immediate mode
val = p.get(key)
p.multi() # --> back to buffered mode
yield (p, val)
p.execute() # raises WatchError if anyone has changed `key`
break # success, break out of while loop
except redis.WatchError:
pass # someone else got there before us, retry.
只要我没有抓到WatchError
,就会很有效,然后我就
File "c:\python27\Lib\contextlib.py", line 28, in __exit__
raise RuntimeError("generator didn't stop")
RuntimeError: generator didn't stop
我做错了什么?
答案 0 :(得分:5)
我认为问题在于你多次产生(当重复任务时),但只输入一次上下文管理器(yield
只是__enter__
方法的语法糖)。因此,只要产量可以多次执行,就会出现问题。
我不完全确定如何以一种好的方式解决这个问题,而且我也无法测试它,所以我只是给出了一些建议。
首先,我会避免产生相当内在的p
;你应该产生一些专门为更新过程做的对象。例如:
with update(KEY) as updater:
updater.value = int(updater.original) + 42
当然,这仍然无法解决多重收益,并且您无法提前获得该对象,因为此时您也不会拥有原始值。因此,我们可以指定负责更新值的委托。
with update(KEY) as updater:
updater.process = lambda value: value + 42
这会将一个函数存储在yielding对象中,然后您可以在上下文管理器中使用该函数继续尝试更新值,直到成功为止。在进入while循环之前,您可以尽早从上下文管理器中获取该更新程序。
当然,如果你已经做到这一点,实际上并不需要留下上下文管理器。相反,你可以创建一个函数:
update(key, lambda value: value + 42)