怎么区分哪个Python线程对应哪个状态对象呢？首先考虑的是我们还有线程的ID。ID存储的正是各个线程的ID，根据这些ID，就可以轻轻松松的进行Python线程内容的寻找了。
每一个线程对应的线程状态对象都保存着这个线程当前的PyFrameObject对象，线程的id这样一些信息。有时候，线程是需要访问这些信息的。比如考虑一个最简单的情形，在某种情况下。
每个线程都需要访问线程状态对象中所保存的thread_id信息，显然，线程A获得的应该是A的thread_id，线程B亦然。倘若线程A获得的是B的thread_id，那就坏菜了。这就意味着Python内部必须有一套机制，这套机制与操作系统管理进程的机制非常类似。
我们知道，在操作系统从进程A切换到进程B时，首先会保存进程A的上下文环境，再进行切换；当从进程B切换回进程A时，又会恢复进程A的上下文环境，这样就保证了进程A始终是在属于自己的上下文环境中运行。
这里的线程状态对象就等同于进程的上下文，Python线程内容同样会有一套存储、恢复线程状态对象的机制。同时，在Python内部，维护着一个全局变量：PyThreadState * _PyThread- State_Current。
当前活动线程所对应的线程状态对象就保存在这个变量里，当Python调度线程时，会将被激活的线程所对应的线程状态对象赋给_PyThreadState_Current，使其始终保存着活动线程的状态对象。
这就引出了这样的一个问题：Python如何在调度进程时，获得被激活线程对应的状态对象？Python内部会通过一个单向链表来管理所有的Python线程的状态对象。当需要寻找一个线程对应的状态对象时，就遍历这个链表，搜索其对应的状态对象。在此后的描述中，我们将这个链表称为“状态对象链表”。
下面我们来看一看实现这个机制的关键数据结构。PyThread_create_key将创建一个新的key。注意，这里的key都是一个整数。而且，当PyThread_create_key***次被调用时（在_PyGILState_Init中的调用正是***次调用），会通过PyThread_allcate_lock创建一个keymutex。
根据我们前面的分析，这个keymutex实际上和GIL一样，都是一个PNRMUTEX结构体，而在这个结构体中，维护着一个Win32下的Event内核对象。这个keymutex的功能就是用来互斥对状态对象链表的访问。
在_PyGILState_Init中，创建的新key被Python维护的全局变量autoTLSkey接收，其中的TLS是Thread Local Store的缩写。这个autoTLSkey将用作Python保存所有线程的状态对象的一个参数，即是图15-6中的key值。也就是说，状态对象列表中所有key结构体中的key值都会是autoTLSkey。
哎，那位看官说了，你看PyThread_create_key返回的是nkeys的递增后的值啊，就是说每create一次，得到的结果都是不同的，怎么能说所有的key都是一样的呢？事实上，在整个Python的源码中，PyThread_create_key只在_PyGILState_Init中被调用了，而这个_PyGILState_Init只会在Python运行时环境初始化时调用一次。
虽然这个核心函数的名字叫find_key，然而我们可以看到，它的作用并不仅仅是搜索，而且还包含了创建的动作。在代码清单15-3的[2]处，find_key会遍历状态对象列表，搜索key和id都匹配的key结构体。
如果搜索成功，则直接返回；而当搜索失败时，find_key会在代码清单15-3的[3]处创建一个新的key结构体，并设置其中的id，key和value，***将其插入到状态对象列表的头部。
在代码清单15-3的[1]和[4]处我们看到了Python确实通过在_PyGILState_Init中创建的keymutex来互斥对状态对象列表的访问。在了解了这个核心函数之后，Python线程内容为状态对象列表所提供的接口就显得非常清晰了。其实，就是简单的链表的插入、删除和查询操作。
【编辑推荐】
