python - Python 中的线程——我错过了什么？

Question

这是我在 Python 中对线程的第一次尝试......它惨遭失败 :) 我想实现一个基本的临界区问题，但发现这段代码实际上没有问题。

问题:为什么我的计数器增量没有问题？运行后计数器不应该有随机值吗？如果递增已经自动执行，或者线程不是并发的，我只能解释这一点......

import threading
import time

turnstile_names = ["N", "E", "S", "W"]
count = 0

class Counter(threading.Thread):
    def __init__(self, id):
        threading.Thread.__init__(self)
        self.id = id

    def run(self):
        global count
        for i in range(20):
            #self.sem.acquire()
            count = count + 1
            #self.sem.release()

def main():
    sem = threading.Semaphore(1)

    counters = [Counter(name) for name in turnstile_names]

    for counter in counters:
        counter.start()

    # We're running!

    for counter in counters:
        counter.join()

    print count
    return 0

if __name__ == '__main__':
    main()

注意:我留下了 acquire() 和 release() 调用的注释以检查差异。我试图在增量之后添加小的 sleep 来调整线程的速度 - 没有区别

解决方案/测试:谢谢凯文(请参阅下面接受的答案)。我只是在测试更改循环变量并得到这个:

Loops    Result
20       99% of the time 80. Sometimes 60.
200      99% of the time 800. Sometimes 600.
2000     Maybe 10% of the time different value
20000    Finally... random numbers! I've yet to see 80000 or 60000.
         All numbers are now random, as originally expected.

我怀疑这似乎意味着线程开销大约是 10^4 增量操作。

另一个有趣的测试(好吧，至少在我看来是这样):

我在递增后添加了time.sleep(random.random()/divisor) 发现，循环计数再次为20:

divisor     result
100         always 4, so the race condition is always there.
1000        95% of the time 4, sometimes 3 or 5 (once 7)
10000       99% of the time NOT 4, varying from 4 to 13
100000      basically same as 10000
1000000     varying from 10 to 70
10000000... same as previous... (even with time.sleep(0))

Answer 1

如果增加每个线程的迭代次数:

def run(self):
    global count
    for i in range(100000):
        #self.sem.acquire()
        count = count + 1
        #self.sem.release()

然后确实发生了竞争条件。您的脚本打印例如175165，预计为 400000。这表明递增不是原子的。

---

递增不是原子的额外证据:CPython 中线程的行为由 Global Interpreter Lock 强制执行.根据维基，

the global interpreter lock, or GIL, is a mutex that prevents multiple native threads from executing Python bytecodes at once.

如果 GIL 具有字节码级别的粒度，那么我们期望增量不是原子的，因为它需要多个字节码来执行，如 dis 模块所示:

>>> import dis
>>> def f():
...     x = 0
...     x = x + 1
...
>>> dis.dis(f)
  2           0 LOAD_CONST               1 (0)
              3 STORE_FAST               0 (x)

  3           6 LOAD_FAST                0 (x)
              9 LOAD_CONST               2 (1)
             12 BINARY_ADD
             13 STORE_FAST               0 (x)
             16 LOAD_CONST               0 (None)
             19 RETURN_VALUE

这里，递增操作由字节码 6 到 13 执行。

---

那么为什么原始代码没有表现出竞争条件呢？这似乎是由于每个线程的预期生命周期较短 - 通过仅循环 20 次，每个线程将完成其工作并在下一个线程开始其自己的工作之前死亡。