先说这个例子在演示什么

这个电影院的例子换了一个角度，主要展示 SimPy 里对了两个非常实用的机制：条件事件和共享事件。

再看场景很生活化。一家电影院，一个售票窗口，同时上映三部电影，每部只卖当场的票。其实，观众陆续到来随机选一部电影。随机想买 n 张票。其实，主要是——一旦某部电影票快卖完了还在排队等这部电影的观众会集体离队。

"集体离队"这件事，用普通的轮询逻辑来实现会很麻烦。SimPy 的做法是：把"售罄"定义成一个事件让所有等待这部电影的观众同时监听它。事件一触发，所有人同时收到信号，各自决定走还是留。这就是共享事件的精髓，

这个例子新增了哪些主要概念

在机器车间的基础上，这个例子引入了三个新东西：

概念	对应用法	作用
普通资源	simpy.Resource	有容量限制的队列资源。先来先得
条件事件	event_a | event_b	等待多个事件中的任意一个触发
共享事件	simpy.Event + .succeed	一个事件被触发，所有监听它的进程同时收到通知
事件结果检查	if my_turn not in result	判断是哪个事件触发了条件，决定后续行为

其中条件事件 | 是这个例子的灵魂。它让一个进程可以同时等待两件事，谁先发生就响应谁——这在现实仿真里极其常见。

代码逐行拆解

参数与导入

from __future__ import annotations # 支持类型注解的前向引用
import random
from typing import Dict,List,NamedTuple,Optional
import simpy
RANDOM_SEED = 42 # 随机种子。保证结果可复现
TICKETS = 30 # 每部电影的初始票数
SELLOUT_THRESHOLD = 5 # 剩余票数低于此值时触发"售罄"事件
SIM_TIME = 180 # 仿真时长

SELLOUT_THRESHOLD = 的设计很有意思：不是等票卖完才宣布售罄，而是剩余不足 X 张时就触发。这模拟了现实中“最终几张票无法满足多人购买需求”的情况。

Theater 数据结构：用 NamedTuple 组织仿真状态

class Theater:
counter: simpy.Resource # 售票窗口，容量为1
至于movies，List # 电影名称列表
available: Dict # 每部电影的剩余票数。键为电影名
sold_out: Dict # 每部电影对应一个"售罄"事件
when_sold_out: Dict] # 记录每部电影的售罄时刻
num_renegers: Dict # 记录每部电影因售罄而离队的人数

NameTuple 在这里只是一个轻量级的数据容器，把电影院相关的所有状态打包在一起，方便在进程间传递。

至于主程序，搭建电影院

print
random.seed
env = simpy.Environment
movies =
ater = Theater(
counter=simpy.Resource,# ★ 普通资源，仅允许一位观众占用窗口
movies=movies,available=dict.fromkeys,sold_out={movie: env.event for movie in movies},# ★ 为每部电影创建独立 Event
when_sold_out=dict.fromkeys,num_renegers=dict.fromkeys
)
env.process) # 启动观众到来进程
env.run # 仿真运行 SIM_TIME 分钟

customer_arrivals：源源不断地制造观众

def customer_arrivals:
"""持续生成新观众。直到仿真结束"""
while True:
yield env.timeout) # 平均每5分钟来一位观众
movie = random.choice # 随机选一部电影
num_tickets = random.randint # 随机想买1~5张票
if ater.available: # 到达时还有余票才生成进程
env.process)
else的观点是，# 已经没有余票直接丢弃，这里不计入 renegers，因为根本没排队
pass

moviegoer：整个例子的主要进程

def moviegoer:
"""
一位观众尝试购买某部电影的票。
老实说，她面临两种可能：
- 轮到自己买票
- 所选影片已经售罄
"""
with ater.counter.request as my_turn:
# ★ 主要：条件事件，同时等待两件事——窗口空闲或影片售罄
result = yield my_turn | ater.sold_out
if my_turn not in result:
# 售罄先触发。我还没轮到就没票了 → 集体离队
ater.num_renegers += 1
return
# 能走到这里说明已经轮到我了现在检查库存是否足够满足需求
if ater.available 

条件事件的工作原理

The following ASCII‑style diagram illustrates how每个观众进程同时监听两个可能：

观众 A
│ │── yield myturn | soldout
│ │ │ │
│ │ │ └───── 谁先触发 ──────┘
│ │ │ │
│ │ ├──► “轮到我” → 去买票
│ │ └──► “影片售罄” → 离队走人
│ ▼ ▼
去买票 离队走人 

当 `sold_out.succeed` 被调用时： sold_out.succeed │ ├──▶ 观众 A 的 yield 返回 │ ├──▶ 观众 B 的 yield 返回 │ ├──▶…└──▶ 所有等待该 event 的进程同步唤醒 `` 一次.succeed`。所有监听者同步响应，这正是“共享事件”的意义。

结果输出与分析

for movie in movies:
if ater.soldout: # ★ Event 对象布尔值表示是否已触发
sellouttime = ater.whensoldout
numrenegers = ater.numrenegers
print(f'Movie "{movie}" sold out {sellout_time:.1f} minutes '
f'after ticket counter opening.')
print

典型输出示例这方面。

Movie "Python Unchained" sold out 73.4 minutes after ticket counter opening.
Number of people leaving queue when film sold out: 12
Movie "Kill Process" sold out 115.7 minutes after ticket counter opening.
Number of people leaving queue when film sold out: 5
Movie "Pulp Implementation" sold out 41.2 minutes after ticket counter opening.
Number of people leaving queue when film sold out: 1
从结果能看出来，“Pulp Implementation”最早售罄，但排队人数最少；而 “Python Unchained” 更受欢迎，导致更多人因提前售罄而离开。

两个例子对比——SimPy 的机制全景

机制	机器车间	电影院
进程	Machine.working / break_machine	moviegoer / customer_arrivals

超时 env.timeout env.timeout

资源请求 repairman.request ater.counter.request

抢占资源 PreemptiveResource — 用于机器车间抢占维修员  — 电影院不涉及抢占  —   —

中断 process.interrupt — 用于机器故障中断工作 — 电影院场景下未使用  

条件事件 — — my_turn | sold_out

共享事件 — — sold_out.succeed

结果检查 — — if my_turn not in result

​

​​

​​​

‌

‏

‍

‌‌

‎

---

读完这个例子，你真正理解了什么？)

• Simplify complex “退订/离队”逻辑 —— 再也不用写繁琐轮询。只要定义一次.succeed,所有相关协程瞬间得到通知。

The power of “or” operator : one process can wait for any of several events and react to whichever happens first.

An event is a first‑class citizen in SimPy – you can create it `)。store it in containers and let any number of processes listen to it.

The pattern scales – you can add more movies、different阈值、甚至多窗口，只需复制相同结构，不必改动主要原因。不过，

If you ever felt lost 娱乐ween “resource request”,“timeout”,and “interrupt”。this example shows m side‑by‑side so you know exactly when to use each.

The overall philosophy: 抽象出“等待某事发生”，让业务代码专注于“如果发生…应该怎么做”，而不是手动维护状态标志。

This mindset translates directly to or domains – 网络请求重试、生产线故障恢复、客服排班等，都可以用相同模式实现。

---