下面文章进行着重分析下什么是Python线程，以及为什么要使用Python线程？对于Python线程的功能特点进行近一步的说明介绍，好了，就随我进入Python线程的世界吧。
比如考虑一个最简单的情形，在某种情况下，每个线程都需要访问线程状态对象中所保存的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，使其始终保存着活动线程的状态对象。#t#
这就引出了这样的一个问题：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运行时环境初始化时调用一次。
那么如何区分哪个线程对应哪个状态对象呢，别忘了，我们还有线程id呢。图15-6中的id存储的正是各个线程的id，根据这个id，显然可以区分不同的线程了。那么图中的key看上去就有点多此一举了，实际上，图15-6中所示的链表结构并非是纯的状态对象链表。
在一个key结构体的value域存储的不是线程的状态对象，而是与线程相关的其他对象时，这个key值就有意义了。假如我们将一种状态对象设为S，而另一种对象设为O，在图15-6所示的链表中，存在着两个与某个线程A相关的key结构体。
显然，对于这两个key结构体，id域是完全一致的，那么当我们需要从这个链表中取出对象O，而并非S时，该用什么来区分O和S呢？正是这个key值。所以实际上在Python中，与每个线程相关的对象可能有多种，而每一种对象都会对应一个key值，这个key值将会被所有的线程在存储这种对象时共享。
对于我们这里关注的线程状态对象，其key值就是autoTLSkey。同样，由于我们这里仅仅关注Python线程机制，所以我们在后面的描述中还是将图15-6中的链表称为线程状态对象链表。
