关于线程的真相-案例研究:机器人和餐具

案例研究:机器人和餐具 (多线程 竞争)

其次，也是更重要的一点，我们过去(现在也仍然不相信)标准的多线程模型，它是共享内存抢占式并发:我们仍然认为没有人能够在“a = a + 1”是不确定的语言中编写正确的程序。

我讲了一个餐厅的故事，里面的类人机器人——ThreadBots——做了所有的工作。在这个比喻里，每个bot就是一个线程。在下面的案例中，我们将了解为什么线程被认为是不安全的。

多线程抢占

#!/usr/bin/env python
# coding=utf-8
"""
@file: case-study-robots-cutlery.py
@time: 2020/6/13 16:15
"""

# 定义 table service 的线程bot

import threading
from queue import Queue


class ThreadBot(threading.Thread):
    def __init__(self):
        # target(.run() 回调方法)
        super(ThreadBot, self).__init__(target=self.manage_table)
        # 初始化餐具
        self.cutlery = Cutlery(knives=0, forks=0)
        self.tasks = Queue()

    def manage_table(self):
        """
        餐桌管理方法
            准备table
            清理table
            shutdown
        :return:
        """
        while True:
            task = self.tasks.get()
            if task == 'prepare table':
                # 从厨房拿出一套餐具
                kitchen.give(to=self.cutlery, knives=4, forks=4)
            elif task == "clear table":
                # 清理桌面，拿回餐具到厨房
                self.cutlery.give(to=kitchen, knives=4, forks=4)
            elif task == "shutdown":
                return


# @attrs 自动初始化 __init__()
from attr import attrs, attrib


@attrs
class Cutlery:
    knives = attrib(default=0)
    forks = attrib(default=0)

    # 拿出
    def give(self, to: 'Cutlery', knives=0, forks=0):
        self.change(-knives, -forks)
        to.change(knives, forks)

    def change(self, knives, forks):
        self.knives += knives
        self.forks += forks


if __name__ == '__main__':
    kitchen = Cutlery(knives=100, forks=1000)
    bots = [ThreadBot() for i in range(10)]

    import sys

    for bot in bots:
        for i in range(int(sys.argv[1])):
            # print(i)
            bot.tasks.put('prepare table')
            bot.tasks.put('clear table')
        bot.tasks.put('shutdown')

    print(f"服务之前的餐具； {kitchen}")

    for bot in bots:
        bot.start()

    for bot in bots:
        bot.join()
    print(f"服务之后： {kitchen}")

运行试试：

# python case-study-robots-cutlery.py 100
# 服务之前的餐具； Cutlery(knives=100, forks=1000)
# 服务之后： Cutlery(knives=100, forks=1000)


# python case-study-robots-cutlery.py 10000
# 服务之前的餐具； Cutlery(knives=100, forks=1000)
# 服务之后： Cutlery(knives=96, forks=996)

第一次运行看上去bot工作的还ok，第二次 Cutlery(knives=96, forks=996) 似乎有bot服务出了异常。

总结一下：

• ThreadBot code 很简单 ，可读性也很好，逻辑也ok
• 100 tables 的情况下 工作正常
• 10000 tables 的情况下，bot似乎应付不过来了
• 较长的测试以不同的、不可复制的方式失败。

这是典型的竞争条件(race condition ) 引发的bug。让我们再看一下问题发生的地方

    def change(self, knives, forks):
        self.knives += knives
        self.forks += forks

内联求和+=在内部(在Python解释器自身的C代码中)由几个单独的步骤实现:

1. 读取 self.knives当前值，放临时位置
2. add 新值，放临时位置
3. 将新的总数从临时位置复制回原始位置。

抢占式多任务处理的问题是，任何忙于这些步骤的线程都可能在任何时候被中断，并且可以给不同的线程机会来处理相同的步骤。

非抢占

让我们加个Lock，保证上面的+=操作不被抢占

from attr import attrs, attrib
from threading import Lock

@attrs
class Cutlery:
    knives = attrib(default=0)
    forks = attrib(default=0)
    lock = Lock()

    # 拿出
    def give(self, to: 'Cutlery', knives=0, forks=0):
        self.change(-knives, -forks)
        to.change(knives, forks)

    def change(self, knives, forks):
        with self.lock:
            self.knives += knives
            self.forks += forks

  python case-study-robots-cutlery.py 10000
  服务之前的餐具； Cutlery(knives=100, forks=1000)
  服务之后： Cutlery(knives=100, forks=1000)