游戏开发后端【免费下载链接】kbengineA MMOG engine of server.项目地址https://gitcode.com/gh_mirrors/kb/kbengine点击查看免费下载本文以 KBEngine 仓库内嵌 Python 3.7.3 标准库文档 library/_thread.rst 为骨架结合仓库内 Modules/_threadmodule.c 的 C 实现源码、Lib/threading.py 的高层封装以及 Lib/test/lock_tests.py 的官方测试用例系统讲解_thread模块的每个常量、函数与锁对象方法。读者读完后将能够用_thread直接创建原生线程、用互斥锁协调共享数据访问并理解 KBEngine 引擎内嵌 Python 解释器的线程基础设施是如何工作的。KBEngine 是一个开源 MMOG 服务器引擎其仓库 kbe/src/lib/python 目录下完整内嵌了一份 Python 3.7.3 源码见 Include/patchlevel.h 中PY_MAJOR_VERSION 3 / PY_MINOR_VERSION 7 / PY_MICRO_VERSION 3的定义引擎的 Python 脚本层baseapp、cellapp、dbmgr等进程内的实体逻辑都运行在这份解释器之上。_thread正是这份解释器中最底层的线程模块——threading模块的所有高层对象Thread、Lock、RLock、Event等都直接建立在_thread之上。一、模块定位Python 线程 API 的底层基石_thread模块为多线程编程提供最原始的底层原语。文档原文将它描述为提供用于操作多个线程也被称为轻量级进程 light-weight processes 或任务 tasks的低级原语多个控制线程共享它们全局的数据空间为了同步模块提供简单的锁也被称为互斥锁 mutexes 或二元信号量 binary semaphores。而threading模块则是在此之上构建的、更易用、更高级的线程 API。该模块在 Python 3.7 中始终可用versionchanged 3.7此模块过去是可选的现在总是可用。在 CPython 源码层面这一点体现在 Modules/_threadmodule.c 中模块通过PyModuleDef结构注册为内建模块_threadPyModuleDef_HEAD_INIT, _thread, ...初始化函数为PyInit__thread。在 KBEngine 的 Python 3.7.3 解释器中C 层线程原语PyThread_start_new_thread、PyThread_allocate_lock等分别对应 POSIX 线程pthread与 Windows 线程两套实现模块因此天然支持 Linux 服务器与 Windows 客户端两种运行环境。从源码看_thread与threading的关系打开 Lib/threading.py 可以清晰看到高层 API 如何依赖底层模块import _thread _start_new_thread _thread.start_new_thread _allocate_lock _thread.allocate_lock ... Lock _allocate_lock第 5 行直接import _thread第 33-34 行把_thread.start_new_thread与_thread.allocate_lock分别保存为_start_new_thread与_allocate_lock作为所有线程启动与锁创建的基础第 73 行Lock _allocate_lock——即threading.Lock本质上就是_thread的锁对象本身第 1255 行from _thread import stack_size——threading.stack_size直接转发到底层实现第 1302 行from _thread import _local as local——线程局部存储threading.local也来自_thread。也就是说理解_thread就等于理解了threading的底层实现原理。二、模块级常量与函数_thread模块定义如下常量与函数均可在 C 实现 Modules/_threadmodule.c 的thread_methods方法表中找到对应注册项。2.1 异常_thread.error线程相关的错误会抛出error异常。自 Python 3.3 起它成为内建异常RuntimeError的别名versionchanged 3.3。在 Modules/_threadmodule.c 中可以看到ThreadError PyExc_RuntimeError; Py_INCREF(ThreadError); PyDict_SetItemString(d, error, ThreadError);因此在实际代码中except _thread.error与except RuntimeError等价。常见的触发场景包括在已持有锁的线程中重复加锁死锁前兆、线程栈大小设置不被平台支持等。2.2 类型_thread.LockTypeLockType是锁对象的类型。它对应的 C 类型为Locktype在 Modules/_threadmodule.c 通过PyType_Ready(Locktype)完成初始化。可以用它做类型判断import _thread lock _thread.allocate_lock() print(isinstance(lock, _thread.LockType)) # True2.3 启动线程start_new_thread(function, args[, kwargs])启动一个新线程并返回其标识符thread identifier。新线程以参数列表args必须是元组执行函数function可选参数kwargs指定关键字参数字典。当函数正常返回时线程静默退出当函数因未捕获异常而终止时会打印堆栈跟踪stack trace随后线程退出但其他线程继续运行——这点与主线程崩溃不同不会波及整个进程。在 C 实现 Modules/_threadmodule.c 中该函数通过PyArg_UnpackTuple(fargs, start_new_thread, 2, 3, ...)接收 2 到 3 个参数function、args、可选kwargs然后调用平台线程创建函数启动原生线程。import _thread import time def worker(name, delay): time.sleep(delay) print(f[{name}] 线程运行完成线程标识: {_thread.get_ident()}) # args 必须是元组kwargs 是字典 tid _thread.start_new_thread(worker, (t1,), {delay: 1.0}) print(已启动线程标识符:, tid) # 注意主线程结束后其他线程可能被终止因此通常需要等待 time.sleep(2)2.4 中断主线程interrupt_main()在主线程中引发KeyboardInterrupt异常。子线程可以用它来打断主线程的阻塞操作。import _thread import time def timeout_killer(): time.sleep(3) print(超时中断主线程...) _thread.interrupt_main() _thread.start_new_thread(timeout_killer, ()) try: while True: time.sleep(0.5) except KeyboardInterrupt: print(主线程被中断执行清理逻辑)注意文档中的 Caveat线程与中断的交互比较特殊——KeyboardInterrupt异常会被任意一个线程接收到只有signal模块可用时即主线程场景中断才会总是投递给主线程。而_thread.interrupt_main()正是把中断定向投递给主线程的手段。2.5 退出当前线程_thread.exit()引发SystemExit异常。当该异常未被捕获时会导致线程静默退出。文档特别指出调用sys.exit()或抛出SystemExit与调用_thread.exit()等价。import _thread def short_lived(): print(线程即将退出) _thread.exit() # 等价于 sys.exit() / raise SystemExit _thread.start_new_thread(short_lived, ())2.6 创建锁allocate_lock()返回一个新的锁对象初始状态为未锁定。这是_thread中最核心的同步原语对应 C 实现中的thread_PyThread_allocate_lock其核心作用保证同一时刻只有一个线程能持有该锁从而保护共享数据的互斥访问。import _thread a_lock _thread.allocate_lock() print(初始是否锁定:, a_lock.locked()) # False2.7 获取当前线程标识get_ident()返回当前线程的线程标识符非零整数。该值本身没有直接含义设计目的是作为魔法饼干magic cookie使用——例如用作字典键来索引线程专属数据。需要注意当线程退出、新线程被创建时线程标识符可能被回收复用因此不要长期缓存标识符来指代某个具体线程。import _thread def show_ident(): print(当前线程 id:, _thread.get_ident()) _thread.start_new_thread(show_ident, ()) print(主线程 id:, _thread.get_ident())2.8 线程栈大小stack_size([size])返回创建新线程时使用的线程栈大小可选参数size指定随后创建的线程的栈大小必须为 0使用平台或配置的默认值或至少 3276832 KiB的正整数若不传size则按 0 处理返回当前设置/默认值若平台不支持修改线程栈大小抛出RuntimeError若指定的栈大小非法抛出ValueError且栈大小保持不变。32 KiB 是目前支持的最小栈大小目的是保证解释器自身有足够的栈空间。部分平台对栈大小有额外限制例如要求最小栈大于 32 KiB或要求按系统内存页大小memory page size的整数倍分配——4 KiB 页很常见在没有更具体信息时建议使用 4096 的倍数作为栈大小。该函数的可用性availability限定为 Windows 与支持 POSIX 线程的系统。import _thread print(当前栈大小:, _thread.stack_size()) # 返回默认/已配置大小 old _thread.stack_size(64 * 1024) # 设置后续线程栈为 64 KiB print(设置前的大小:, old) _thread.stack_size(0) # 恢复为平台默认需要说明的是KBEngine 服务端进程中大量脚本线程由引擎统一调度通常建议保持默认栈大小传 0除非你明确知道脚本调用栈很深、需要加大栈空间。2.9 超时上限_thread.TIMEOUT_MAXLock.acquire的timeout参数允许的最大值。指定超过此值的超时会抛出OverflowError。该常量自 Python 3.2 起提供versionadded 3.2。在 C 实现 Modules/_threadmodule.c 中可以看到它的计算方式timeout_max (_PyTime_t)PY_TIMEOUT_MAX * 1e-6; time_max _PyTime_AsSecondsDouble(_PyTime_MAX); timeout_max Py_MIN(timeout_max, time_max); /* Round towards minus infinity */ timeout_max floor(timeout_max); v PyFloat_FromDouble(timeout_max); PyModule_AddObject(m, TIMEOUT_MAX, v);即TIMEOUT_MAX是PY_TIMEOUT_MAX内部时间微秒上限换算成秒后再与_PyTime_MAX取最小值并向下取整得到的浮点数。三、锁对象LockType的完整方法锁对象支持以下方法。3.1lock.acquire(waitflag1, timeout-1)获取锁这是锁对象最核心的方法。分三种模式无条件阻塞获取不传任何可选参数如果必要则等待直到锁被其他线程释放。同一时刻只有一个线程能获取锁——这正是锁存在的意义。非阻塞尝试获取传入整型waitflag0只在能立即获得锁时才获取不等待。带超时的获取传入正的浮点timeouttimeout以秒为单位指定返回前的最长等待时间负的timeout表示无限期等待。限制如果waitflag为 0非阻塞则不能指定timeout。返回值成功获取返回True否则返回False。versionchanged 3.2timeout参数是新增的versionchanged 3.2在 POSIX 上锁的获取现在可以被信号中断。在 Modules/_threadmodule.c 可以看到超时参数在 C 层被转换为微秒级别if (microseconds PY_TIMEOUT_MAX)超出上限会走异常路径。import _thread import time lock _thread.allocate_lock() # 模式一阻塞获取 lock.acquire() print(已持有锁) # 模式二非阻塞尝试 if lock.acquire(0): print(立即获取成功) # 不可能执行到这里 else: print(锁已被占用获取失败) # 会执行到这里 lock.release() # 模式三带超时获取 if lock.acquire(timeout0.5): print(1 秒内获得锁) lock.release()3.2lock.release()释放锁。锁必须已经被获取过但不一定要由同一个线程释放——这是_thread锁与普通可重入锁RLock的重要区别底层锁并不记录持有者线程。也就是说线程 A 加的锁可以由线程 B 释放。import _thread lock _thread.allocate_lock() lock.acquire() lock.release() # 谁持有、谁释放均可 print(锁已释放:, lock.locked()) # False3.3lock.locked()返回锁的状态若已被某个线程获取则返回True否则返回False。常用于非阻塞轮询前的状态探测。3.4 锁的with语句支持除了上述方法锁对象还可以直接用于with语句。文档给出的标准示例import _thread a_lock _thread.allocate_lock() with a_lock: print(a_lock is locked while this executes)等价于a_lock.acquire() try: print(a_lock is locked while this executes) finally: a_lock.release()注意with语句在退出时必定释放锁即使块内抛出异常也不会造成死锁因此这是推荐写法。官方测试 Lib/test/lock_tests.py 的test_with用例专门验证了with lock:在正常退出与抛出TypeError两种情况下锁都会被正确释放。3.5 锁对象在 C 层的形态从 Modules/_threadmodule.c 的lock_doc文档字符串可以看到 CPython 对锁对象的权威描述A lock object is a synchronization primitive. ... acquire() -- lock the lock, possibly blocking until it can be obtained; release() -- unlock of the lock; locked() -- test whether the lock is currently locked. A lock is not owned by the thread that locked it; another thread may unlock it. A thread attempting to lock a lock that it has already locked will block until another thread unlocks it. Deadlocks may ensue.这段描述点出了_thread锁的两个关键特性锁不被持有者线程所有其他线程可解锁以及同一线程对自己已持有的锁再次加锁会阻塞直到解锁——这正是死锁deadlock的经典成因也正是threading.RLock可重入锁存在的理由。四、官方测试对锁行为的验证KBEngine 内嵌 Python 的标准库测试 Lib/test/lock_tests.py 对上述行为做了系统性验证可作为行为契约的权威参照test_acquire_release第 110 行加锁后释放验证基本流程test_try_acquire/test_try_acquire_contended第 116-129 行acquire(False)非阻塞获取——空闲锁立即获取成功返回True被占用的锁立即失败返回Falsetest_acquire_contended第 131-145 行5 个线程同时争抢一个锁只有持有者释放后其他线程才能依次获取test_with第 147-161 行with语句正常与异常路径下锁均被正确释放test_timeout第 182-197 行不能为非阻塞获取指定 timeout非法负超时抛出ValueError超过TIMEOUT_MAX 1的超时抛出OverflowErrortimeoutTIMEOUT_MAX本身合法带正超时的获取在锁空闲时立即成功test_state_after_timeout第 258-263 行超时返回后锁保持未获取状态assertFalse(lock.acquire(timeout0.01))。这些用例同时覆盖了纯_thread锁LockTests与threading.Lock再次印证二者实为同一对象。五、重要注意事项Caveats原文档给出的五大注意事项是编写多线程代码时必须牢记的边界行为线程与中断的奇怪交互KeyboardInterrupt异常会被任意一个线程接收到当signal模块可用时主线程场景中断总是投递给主线程。sys.exit/SystemExit与_thread.exit等价三者都会导致线程静默退出。无法中断锁的acquireKeyboardInterrupt只会发生在锁被获取之后等待获取期间不会被中断——因此长等待可能表现为卡住务必善用timeout参数。主线程退出时其他线程的生死由系统决定在大多数系统上其他线程会被直接杀掉不会执行try...finally子句也不会执行对象析构函数。主线程退出时不做常规清理除了会执行try...finally子句外标准 I/O 文件不会被刷新flush。其中第 3、4 条对服务器脚本有直接警示不要让主线程轻易返回也不要依赖子线程的finally或析构逻辑做关键清理。KBEngine 各服务进程baseapp、cellapp 等的主循环长期运行、线程生命周期由引擎组件管理因此脚本侧通常不应自行创建裸线程——如需并发逻辑建议优先使用引擎提供的回调与定时器机制或在确有需要时使用threading高层模块并严格控制线程生命周期。六、实战总结_thread是理解 Python 线程模型的最小知识集功能API要点启动线程start_new_thread(fn, args[, kwargs])args必须是元组未捕获异常仅打印栈后线程退出创建锁allocate_lock()初始未锁定类型为LockType获取锁acquire(waitflag1, timeout-1)支持阻塞 / 非阻塞0/ 带超时三种模式释放锁release()不要求由持有者线程释放查询锁locked()返回布尔状态线程标识get_ident()非零整数可作字典键会被回收复用栈大小stack_size([size])最小 32 KiB建议取 4096 的倍数退出线程exit()等价于sys.exit()/raise SystemExit中断主线程interrupt_main()向主线程投递KeyboardInterrupt超时上限TIMEOUT_MAX超过会抛OverflowError在实际工程中_thread的价值在于它足够简单、足够快且是threading的全部底层来源。KBEngine 内嵌的这份 Python 3.7.3 标准库源码位于 kbe/src/lib/python模块文档位于 Doc/library/_thread.rstC 实现在 Modules/_threadmodule.c随时可供深入阅读读者可以按图索骥从文档到实现再到测试用例完整掌握这一底层线程 API 的每一个细节。赞分享游戏开发后端【免费下载链接】kbengineA MMOG engine of server.项目地址https://gitcode.com/gh_mirrors/kb/kbengine点击查看免费下载相关推荐KBEngine 内嵌 Python 3.7 的 C API 数字协议Number Protocol全面解析KBEngine 内嵌 Python 3.7 的 C API 数字协议Number Protocol全面解析 导读 本文以 KBEngine 仓库内置的 P游戏开发后端KBEngine 内嵌 CPython 3.7 的 contextvars C API 完全指南PyContext 与 PyContextVar 接口详解KBEngine 内嵌 CPython 3.7 的 contextvars C API 完全指南PyContext 与 PyContextVar 接口详解 导游戏开发后端KBEngine 内嵌 Python 3.7 的 Codec 注册机制C API 函数族深度解析KBEngine 内嵌 Python 3.7 的 Codec 注册机制C API 函数族深度解析 本篇技术指南以 KBEngine 仓库内嵌 Python 3游戏开发后端上一篇Mac Mouse Fix多语言文档管理完整指南构建高效的国际化协作流程下一篇MPC-BEWindows平台开源媒体播放器的架构革新与技术演进创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考