【Visual Studio】Windows窗体应用程序代码中的【STAThreadAttribute】是什么?

出处:

// WinForm.cpp: 主项目文件。

#include "stdafx.h"
#include "Form1.h"

using namespace WinForm;

[STAThreadAttribute]
int main(array<System::String ^> ^args)
{
	// 在创建任何控件之前启用 Windows XP 可视化效果
	Application::EnableVisualStyles();
	Application::SetCompatibleTextRenderingDefault(false); 

	// 创建主窗口并运行它
	Application::Run(gcnew Form1());
	return 0;
}

引用:COM线程模型详解
线程模型是一种数学模型，专门针对多线程编程而提供的算法，但也仅是算法，不是实现。本文讲解COM提出的各个类型的线程模型，再说明COM运行时期库是如何实现它们的，就像说明Windows是如何实现线程这个数学模型的一样，最后指明一下跨套间调用和各种类型套间编写的要求以帮助理解。希望读者对于Windows操作系统的线程这个概念相当熟悉，对何谓“线程安全的”亦非常了解。

　　COM线程模型

　　COM提供的线程模型共有三种：Single-Threaded Apartment（STA 单线程套间）、Multithreaded Apartment（MTA 多线程套间）和Neutral Apartment/Thread Neutral Apartment/Neutral Threaded Apartment（NA/TNA/NTA 中立线程套间，由COM+提供）。虽然它们的名字都含有套间这个词，这只是COM运行时期库（注意，不是COM规范，以下简称COM）使用套间技术来实现前面的三种线程模型，应注意套间和线程模型不是同一个概念。COM提供的套间共有三种，分别一一对应。而线程模型的存在就是线程规则的不同导致的，而所谓的线程规则就只有两个：代码是线程安全的或不安全的，即代码访问公共数据时会或不会发生访问冲突。由于线程模型只是个模型，概念上的，因此可以违背它，不过就不能获得COM提供的自动同步调用及兼容等好处了。

　　STA 一个对象只能由一个线程访问（通过对象的接口指针调用其方法），其他线程不得访问这个对象，因此对于这个对象的所有调用都是同步了的，对象的状态（也就是对象的成员变量的值）肯定是正确变化的，不会出现线程访问冲突而导致对象状态错误。其他线程要访问这个对象，必须等待，直到那个唯一的线程空闲时才能调用对象。注意：这只是要求、希望、协议，实际是否做到是由COM决定的。如上所说，这个模型很像Windows提供的窗口消息运行机制，因此这个线程模型非常适合于拥有界面的组件，像ActiveX控件、OLE文档服务器等，都应该使用STA的套间。

　　MTA 一个对象可以被多个线程访问，即这个对象的代码在自己的方法中实现了线程保护，保证可以正确改变自己的状态。这对于作为业务逻辑组件或干后台服务的组件非常适合。因为作为一个分布式的服务器，同一时间可能有几千条服务请求到达，如果排队进行调用，那么将是不能想像的。注意：这也只是一个要求、希望、协议而已。

　　NA 一个对象可以被任何线程访问，与MTA不同的是任何线程，而且当跨套间访问时（后面说明），它的调用费用（耗费的CPU时间及资源）要少得多。这准确的说都已经不能算是线程模型了，它是结合套间的具体实现而提出的要求，它和MTA不同的是COM的实现方式而已。

    COM套间

　　Apartment被翻译成套间或是单元，是线程模型的一个实现者，就像在操作系统课程中讲到的线程只是一个数学模型，而Windows的线程、进程是它（数学模型的线程、进程）的实现者。套间只是逻辑上的一个概念，实现时只是一个结构（由COM管理）而已，记录着相关信息，如它的种类（只能是上面那三个，至少现在是），并由COM根据那个结构进行相应的处理。下面说明这三种套间的实现方式：

　　STA套间 一个套间如果是STA，那么那个套间有且只有一个线程和其关联，有多个对象或没有对象和其关联，就像有多个线程和一个进程关联一样，也就是说套间那个结构和某个线程及多个对象之间有关系，关系具体是什么由COM说得算，幸运的是COM正是按照上面的线程模型来定义互相之间关系的。根据上面的算法，很容易就知道只有这个线程可以访问这个套间里的对象。

　　COM是通过在STA套间里的线程中创建一个隐藏窗口，然后外界（这个套间外的线程）对这个对象的调用都转变成对那个隐藏窗口发送消息，然后由这个隐藏窗口的消息处理函数来实际调用组件对象的方法来实现STA的规则的。之所以使用一个隐藏窗口是为了方便组件代码的编写——只需调用DispatchMessage即可将方法调用的消息和普通的消息区分开来（通过隐藏窗口的消息处理函数）。外界对这个对象的调用都将转变成对这个隐藏窗口的消息发送来实现同步。至于COM如何截获外界对对象的调用，则是利于代理对象，后面再说明。

　　值得注意的是，如果使用标准汇集法生成代理对象，则代理对象会根据是进程内还是进程外的跨套间调用，来决定具体操作。如果外界线程和STA线程在同一进程内，则代理对象将直接向STA线程中的隐藏窗口发送消息；如果不在同一进程内（包括远程进程），代理对象将向RPC管理的一个线程池请求一个线程（RPC线程）来专门向另一进程中的STA线程的隐藏窗口发送消息，而不是代理对象直接发送消息，以防止外界线程由于网络等不稳定因素而导致挂起。

　　因为COM利用消息机制来实现STA，因此STA套间里的线程必须实现消息循环，否则COM将不能实现STA的要求。

　　MTA套间 这种类型的套间可以和多个线程及多个或没有对象相关联。根据上面的MTA模型，可知只有这个套间里的线程才能访问这个套间里的对象，和STA不同的只是可以多个线程同时访问对象。

　　外界（不属于这个套间的线程）对这个套间里的对象的调用将会导致调用线程（外界线程，也就是STA线程，因为NA没有线程）挂起，然后向RPC管理的一个线程池请求一个线程（RPC线程，并已经进入了这个MTA套间）以调用那个对象的方法。对象返回后，调用线程被唤醒，继续运行。虽然可以让STA线程直接调用对象（而不用像前述的挂起等待另一个线程来调用对象），但这是必须的，因为可能会有回调问题，比如这个MTA线程又反过来回调外界线程中的组件对象（假设客户本身也是一个组件对象，这正是连接点技术），如果异步回调将可能发生错误。

　　反过来，MTA的线程访问STA里的对象时，COM将把调用转换成对STA线程里那个隐藏窗口的一个消息发送，返回后再由COM转成结果返回给MTA的线程（如果使用标准汇集法生成标准代理对象，则发生的具体情况就如上面STA套间所述）。因此STA和MTA都是只能由它们关联的线程调用它们关联的对象。而根据上面所说，当MTA调STA或STA调MTA，都会发生线程切换，也就是说一个线程挂起而换成执行另一个线程。这是相当大的消耗（需要从内核模式向用户模式转换，再倒转好几回），而NA就是针对这个设计的。

　　NA套间 这种套间只和对象相关联，没有关联的线程，因此任何线程都可以直接访问里面的对象，不存在STA的还是MTA的。

　　外界（其实就是任何线程）对这个套间里面的调用都不需要挂起等待，而是进入NA套间，直接调用对象的方法。NA套间是由COM+提供的，COM+中的每个对象都有一个环境和其相绑定，环境记录了必要的信息，并监听对对象的每一次调用，以保证当将对象的接口指针成员变量进行传递或回调时其操作的正确性（保证执行线程在正确的套间内，MTA线程就是通过将自己挂起以等待STA线程的消息处理完毕来保证的），从而避免了调用线程的挂起，因此这个代理（其实也就是环境的一部分）被称作轻量级代理（相对于STA套间和MTA套间的重量级代理——需要挂起调用线程，发生线程切换）。

　　这个轻量级代理并不是永远都不发生线程切换。当NA对象里有个对指向一个STA对象的指针的调用而调用线程不是那个STA对象关联的线程时，调用将会转成向被调用的STA对象的关联线程发送消息，此时照样会发生线程切换。同理，如果那个对象是MTA的，而调用线程是STA线程时，依旧发生线程切换。不过除此以外的大多数情况（即不在NA对象的方法中调用另一个套间对象的方法）都不会发生线程切换，即使出现上面的情况也只有必要（MTA调NA再调MTA就不用切换）才切换线程。

　　根据上面所说，STA其实和MTA逻辑上是完全一样的，只是一个是关联一个线程，一个是关联多个线程而已。但把它们分开是必要的，因为线程安全就是针对是一个线程还是多个线程。而NA之所以不关联线程是因为它的目的是消除上面跨套间调用时产生的线程切换损耗，关联线程没有任何意义。

　　COM强行规定（不遵守也没辙，因为全是COM实现套间的，根本没有插手的余地）一个进程可以拥有多个STA的套间，但只能拥有一个MTA套间和一个NA套间，我想这应该已经很容易理解了（要两个MTA套间或NA套间干甚？）。

    套间生成规则

　　线程在进行大多数COM操作之前，需要先调用CoInitialize或CoInitializeEx。调用CoInitialize告诉COM生成一个STA套间，并将当前的调用线程和这个套间相关联。而调用CoInitializeEx( NULL, COINIT_MULTITHREADED );告诉COM检查是否已经有了一个MTA套间，没有则生成一个MTA套间，然后将那个套间和调用线程相关联。接着在调用CoCreateInstance或CoGetClassObject等创建对象的函数时，创建的对象将以一个特定规则决定和哪个套间相关联（后叙）。这样完成后，就完成了线程、对象和套间的关联（或绑定）。

　　前面提到的决定对象去向的规则如下。

　　当是进程内组件时，根据注册表项InprocServer32ThreadingModel和线程的不同，列于下表：

创建线程关联的套间种类	ThreadingModel键值	组件对象最后所在套间
STA	Apartment	创建线程的套间
STA	Free	进程内的MTA套间
STA	Both	创建线程的套间
STA	""或Single	进程内的主STA套间
STA	Neutral	进程内的NA套间
MTA	Apartment	新建的一个STA套间
MTA	Free	进程内的MTA套间
MTA	Free	进程内的MTA套间
MTA	Both	进程内的MTA套间
MTA	""或Single	进程内的主STA套间
MTA	Neutral	进程内的NA套间

进程内的主STA套间是进程中第一个调用CoInitialize的线程所关联的套间（即进程中的第一个STA套间）。后面说明为什么还来个进程内的主STA套间。

　　当是进程外组件时，由主函数调用CoInitializeEx或CoInitialize指定组件所在套间，与上面的相同，CoInitialize代表STA，CoInitializeEx( NULL, COINIT_MULTITHREADED );代表MTA，没有NA。因为NA是COM+提供的，而COM+服务只能提供给进程内服务器，因此只使用上面的注册表项的规则决定DLL组件是否放进NA套间，而没有提供类似CoInitializeEx( NULL, COINIT_NEUTRAL );来处理EXE组件。而且如果可以使用CoInitializeEx( NULL, COINIT_NEUTRAL );将导致调用线程和NA套间相关联了，违背了NA的线程模型，这也是为什么ThreadingModel键在InprocServer32键下。

　　跨套间调用

　　STA线程1创建了一个STA对象，得到接口指针IABCD，接着它发起STA线程2，并且将IABCD作为线程参数传入。在线程2中，调用IABCD::Abc()方法，成功或者失败天注定。由于线程2所在的STA套间不同于线程1所在的STA套间，这样线程2就跨套间调用另一个套间的对象了。按照前述的STA规则，IABCD::Abc()应该被转成消息来发送，而如果如上面做法，可以，编译通过，不过运行就不保证了。

　　COM之所以能够实现前面所说的那些规则（STA、MTA、NA），是因为跨套间调用时，被调用的对象指针是指向一个代理对象，不是组件对象本身。而那个代理对象实现前述的那三个实现算法（转成消息发送，线程切换等），而一般所说的代理/占位对象（Proxy/Stub）等其实都只是指进行汇集工作的代码（后述）。而按照上面直接通过线程参数传入的指针是直接指向对象的，所以将不能实现STA规则，为此COM提供了如下两个函数（还有其他方式，如通过全局接口表GIT）来方便产生代理：CoMarshalInterface和CoUnmarshalInterface（如果在同一进程内的线程间传递接口指针，则可以通过这两个函数来进一步简化代码的编写：CoMarshalInterThreadInterfaceInStream和CoGetInterfaceAndReleaseStream）。
现在重写上面代码，线程1得到IABCD后，调用CoMarshalInterface得到一个IStream，然后将IStream传入线程2，在线程2中，调用CoUnmarshalInterface得到IABCD，现在这个IABCD*就是指向代理对象的，而不是组件对象了。

　　因此，前面所说过的所有线程模型的算法都是通过代理对象实现的。要跨套间时，使用CoMarshalInterface将代理对象的CLSID和其与组件对象建立联系的一些必要信息（如组件对象的接口指针）列集（Marshaling）到一个IStream中，再通过任何线程间通信手段（如全局变量等）将IStream传到要使用的线程中，再用CoUnmarshalInterface散集（Unmarshaling）出接口以获得指向代理对象的接口指针。因此之所以要获得代理对象的指针是因为想使用COM提供的线程模型（但在COM+中，这不是唯一的理由），如果不想使用大可不必这么麻烦（不过后果自负），并没有强制要求必须那么做。

　　当线程1和线程2都是MTA时，则可以像最开始说的那样，直接传递IABCD*到线程2中，因为MTA线程模型同意多个线程同时直接调用对象，线程1和线程2在同一个MTA套间中，而那个对象通过某种形式（如ThreadingModel = Free）向COM声明了自己支持MTA线程模型。

　　而当a.exe的线程1和b.exe的线程2都是MTA时，则依旧需要像上面那样进行接口指针的汇集（列集→传输→散集这个过程）以得到指向代理而非对象的指针，即使线程1和线程2都是在MTA套间中，却是在两个不同的MTA套间中，因此是跨套间调用，需要汇集操作。

　　汇集代码

　　前面已经说明了套间的规则都是通过对代理对象而非组件对象发起调用以截取对组件对象的调用由代理对象来实现的。代理对象要和组件对象交互，将方法参数传递给组件对象，需要使用到汇集技术，也就是列集→传输→散集这个过程。

　　列集（Marshaling）指将信息以某种格式存为流（IStream*）形式的操作；散集（Unmarshaling）则是列集的反操作，将信息从流形式中反还出来；传输则只是流形式的传递操作。

　　这里经常发生误会。前面的CoMarshalInterface所做的列集，是将代理对象的CLSID及一些持久信息（用于初始化代理对象）格式化为一种格式（网络数据描述——Network Data Representation）后放到一个流对象中，可以通过网络（或其他方式）将这个流对象传递到客户机，由客户通过CoUnmarshalInterface从传来的流对象中反还出代理对象的CLSID和初始化用的一些持久信息，生成代理对象并使用持久信息初始化它以用于汇集操作。这就是发生误会的地方——这里的汇集操作不同于上面的汇集操作，其汇集的是接口方法的参数而不是什么CLSID和一些初始化信息。

　　因此CoMarshalInterface和CoUnmarshalInterface是用于汇集接口指针的，再准确点应该是用于生成代理对象的。代理对象应由读者自己实现，用于汇集接口方法的参数。一般有两种代理对象的实现方式：自定义汇集和标准汇集。

　　对于自定义汇集，组件需实现IMarshal接口和一个代理组件（即完全实现真正组件所有接口的一个副本，实现了汇集方法参数及线程模型的规则，也必须实现IMarshal接口），并将这个代理组件在客户机上注册，以保证代理对象的正确生成。注意：如果参数中有接口指针，必须用CoMarshalInterface和CoUnmarshalInterface进行汇集，否则无法实现正确的线程模型，且代理组件是线程模型的实现者，这点组件必须自己保证（如发送消息等）。

　　对于标准汇集，组件无需实现IMarshal接口及代理组件，代替的，组件则需要为自己生成一个代理/占位组件（Proxy/Stub），其由于可通过MIDL由IDL文件自动生成，效率高，代码的正确性有保证，因而被鼓励使用。COM提供了一个标准代理对象的实现，其通过聚合组件的代理/占位组件以表现出其好像是组件的代理对象。与自定义汇集一样，需要将这个代理/占位组件在客户机上注册以保证代理对象的正确生成。

　　至于这两种汇集的具体工作机理，由于与本文无关，在此不表，这里仅仅只为消除代理对象和代理/占位组件之间的混淆。
　　注意：对于将运行于NA套间的组件，由于COM+的强制要求，其必须使用标准汇集进行代理对象的生成而不是自定义汇集（COM+运行时期库重写了标准代理对象来截获对组件对象的调用和其自身的某些特殊处理——如保证NA套间正确工作）。

    套间实现规则

　　如前面所说，COM的套间机制要成功，必须服务器（组件）、客户和COM运行时期库三方面合力实现，其中有任何一方不按着规矩来，将不能实现套间机制的功能，不过这并不代表什么错误，套间机制不能运作并不代表程序会崩溃，只是不能和其他COM应用兼容而已。

　　比如：对象中的属性1在设计的算法中肯定不会被两个以上的线程写入，只是会被多个线程同时读出而已，因此不用同步，可以用MTA，但对象的属性2却可能被多个线程写入，因此决定使用STA。从而在客户端，通过前面说的CoMarshalInterface和CoUnmarshalInterface将对象指针传到那个只会写入对象的属性1的线程，其实这时就可以直接将对象指针传到这个线程，而不用想上面那样麻烦（而且增加了效率），但是就破坏了COM的套间规矩了——两个线程可以访问对象，但对象在STA套间中。所以？！！什么事都不会发生，因为已经准确知道这个算法不会捅娄子（线程访问冲突），即使破坏COM的规矩又怎样？！而且组件仍可以和其他客户兼容，因为不按规矩来的是客户，与组件无关。不过如果组件破坏规矩，那么它将不能和每一个客户兼容，但并不代表它和任何客户都不兼容。这里其实就是客户和组件联合起来欺骗了COM运行时期库。

　　上面的例子只是想帮助读者加深对套间的理解，实际中应该尽量保持和COM规范的兼容性（但不兼容并不代表是错误的）。客户要做的工作前面已经说过了（那两个函数或全局接口表或其他只要正确的方式），下面说明组件应该做的工作。组件可以存在于四个套间中（多了一个主STA套间），所需工作分别如下：

　　STA 当一个组件是STA时，它必须同步保护全局变量和静态变量，即对全局变量和静态变量的访问应该用临界段或其他同步手段保护，因为操作全局和静态变量的代码可以被多个STA线程同时执行，所以那些代码的地方要进行保护。比如对象计数（注意，不是引用计数），代表当前组件生成的对象个数，当减为零时，组件被卸载。此变量一般被类厂对象使用，还好ATL和MFC已经帮我们实现了缺省类厂，这里一般不用担心，但自定义的全局或静态变量得自己处理。

　　主STA 与STA唯一的不同是这是傻瓜型的，连静态和全局变量都可以不用线程保护，因为所有不是安全访问静态和全局变量的对象都通过主线程（第一个调用CoInitialize的线程）的消息派送机制运行，因此不安全的访问都被集中到了一个线程的调用中，因而调用被序列化了，也就实现了对静态和全局变量的线程保护。至于为什么是主线程，因为进程要使用STA，则一定会创建主线程，所以一定可以创建主STA。因此主STA并不是什么第四种套间，只是一个STA套间，不过关联的是主线程而已，由于它可以被用作保护静态和全局变量而被单独提出来说明。因此一个进程内也只有一个主STA套间。

　　MTA 必须对组件中的每个成员和全局及静态变量的访问使用同步手段进行保护，还应考虑线程问题，即不是简单地保护访问即可，还应注意线程导致的错误的操作，最经典的就是IUnknown::Release()。

DWORD IUnknown::Release()
{
 DWORD temp = InterlockedDecreament( &m_RefCount );
 if( !temp ) // 不能用m_RefCount，原因请自己思考
 delete this; // 因此不是只要用原子访问函数保护了m_RefCount的访问就行了
 return temp; // 前面对全局变量的保护也和此类似，要考虑线程问题
}

　　如果读者对自己多线程编程的技术没有信心，建议最好不要编写可以存在于MTA套间的组件，不过就不能获得MTA的高性能了。

　　在编写MTA时还应该注意到线程亲缘性（thread affinity）。没有线程亲缘性是指没有任何线程范围的成员变量，比如线程局部存储（TLS）、窗口句柄等。也就是说在MTA中不能保存任何记录着TLS内存的指针或窗口句柄，如果保存将没有意义（比如A线程记录的内存空间对B线程来说是无效的，因为TLS构造了一个线程相关的内存空间，就像每个进程都有自己的私有空间）。而不幸地MFC在它的底层运作机制的实现中大量使用了TLS，如模块线程状态、线程状态等。正是由于这个原因，MFC不能编写在MTA中运行的组件。

　　NA 由于可能会多个线程同时访问NA套间的对象，因此和MTA一样，其不能有线程亲缘性并需要保护每个成员和全局及静态变量。而关于NA的轻量级代理，是由COM+运行时期库生成的，读者完全不用操心（只需将那个组件的ThreadingModel键值赋值为“Neutral”即可）。

　　前面提到过有一种进程内组件的ThreadingModel键值可以被赋为“Both”，这种组件很像NA，哪个套间都可能直接访问它，但只是可能，而NA组件是可以，这点可以从前面的那个进程内组件所属套间的规则表中看出。这种组件可以支持一种称作自由线程汇集器（FTM——Free Threaded Marshaler）的技术，由于其与本文题目无关，在此不表。当Both的组件使用了自由线程汇集器时，除了满足MTA的要求以外（上面所说的线程安全保护和没有线程相关性），还要记录传进来的接口指针的中立形式（比如IStream*，通过CoMarshallInterface得到），以防止对客户的回调问题。

　　最后只是提醒一下，有3个STA套间，STA1、STA2和STA3。STA1用CoMarshallInterface得到的IStream*传到STA2中通过CoUnmarshalInterface得到的代理和在STA3中同样通过CoUnmarshalInterface得到的代理不同，不能混用。因为当STA2和STA3调用在STA1的对象时，STA1如果回调（连接点技术就是一种回调）调用者，则STA2和STA3的代理能分别正确的指出需要让哪个线程执行回调操作，即向哪个线程发送消息，因此不能混用。