在本系列的上一篇文章中,我们重点讨论了线程关联性对service和callback的操作执行的影响:在service host的时候，可以设置当前线程的SynchronizationContext，那么在默认情况下，service操作的执行将在该SynchronizationContext下执行（也就将service操作包装成delegate传入SynchronizationContext的Send或者Post方法）；同理，对于Duplex同行方式来讲，在client调用service之前，如果设置了当前线程的SynchronizationContext，callback操作也将自动在该SynchronizationContext下执行。
对于Windows Form Application来讲，由于UI Control的操作执行只能在control被创建的线程中被操作，所以一这样的方式实现了自己的SynchronizationContext（WindowsFormsSynchronizationContext）：将所有的操作Marshal到UI线程中。正因为如此，当我们通过Windows Form Application进行WCF service的host的时候，将会对service的并发执行带来非常大的影响。
详细讲，由于WindowsFormsSynchronizationContext的Post或者Send方法，会将目标方法的执行传到UI主线程，所以可以说，所有的service操作都在同一个线程下执行，如果有多个client的请求同时抵达，他们并不能像我们希望的那样并发的执行，而只能逐个以串行的方式执行。(Source Code从这里下载)
我们可以通过一个简单的例子证明：在默认的情况下，当我们通过Windows Form Application进行service host的时候，service的操作都是在同一个线程中执行的。我们照例创建如下的四层结构的WCF service应用：
![[原创]WCF后续之旅(12): 线程关联性（Thread Affinity）对WCF并发访问的影响](http://images.cnblogs.com/likecs_com/artech/WindowsLiveWriter/WCF12WCF_112BE/image_2.png "[原创]WCF后续之旅(12): 线程关联性（Thread Affinity）对WCF并发访问的影响")
1、Contract:IService
namespace Artech.ThreadAffinity2.Contracts
2: {
3: [ServiceContract]
interface IService
5: {
6: [OperationContract]
void DoSomething();
8: }
9: }
namespace Artech.ThreadAffinity2.Services
2: {
class Service:IService
4: {
static ListBox DispalyPanel
6: { get; set; }
7:
static SynchronizationContext SynchronizationContext
9: { get; set; }
10:
#region IService Members
12:
void DoSomething()
14: {
15: Thread.Sleep(5000);
int threadID = Thread.CurrentThread.ManagedThreadId;
17: DateTime endTime = DateTime.Now;
delegate
19: {
,
21: endTime, threadID));
null);
23: }
24:
#endregion
26: }
27: }
为了演示对并发操作的影响，在DoSomething（）中，我将线程休眠10s以模拟一个相对长时间的操作执行；为了能够直观地显示操作执行的线程和执行完成的时间，我将他们都打印在host该service的Windows Form的ListBox中，该ListBox通过static property的方式在host的时候指定。并将对ListBox的操作通过UI线程的SynchronizationContext（也是通过static property的方式在host的时候指定）的Post中执行（实际上，在默认的配置下，不需要如此，因为service操作的执行始终在Host service的UI线程下）。
3、Hosting
我们将service 的host放在一个Windows Form Application的某个一个Form的Load事件中。该Form仅仅具有一个ListBox：
namespace Artech.ThreadAffinity2.Hosting
2: {
class HostForm : Form
4: {
private ServiceHost _serviceHost;
6:
public HostForm()
8: {
9: InitializeComponent();
10: }
11:
object sender, EventArgs e)
13: {
, Thread.CurrentThread.ManagedThreadId));
typeof(Service));
delegate
17: {
;
19: };
this.listBoxResult;
21: Service.SynchronizationContext = SynchronizationContext.Current;
this._serviceHost.Open();
23: }
24:
object sender, FormClosedEventArgs e)
26: {
this._serviceHost.Close();
28: }
29: }
30: }
31:
在HostForm_Load，先在ListBox中显示当前线程的ID，然后通过Service.DispalyPanel和Service.SynchronizationContext 为service的执行设置LisBox和SynchronizationContext ，最后将servicehost打开。下面是Configuration：
>
>
>
>
>
/>
>
>
/>
>
>
>
>
>
>
4、Client
我们通过一个Console Application来模拟client端程序，先看看configuration：
>
>
>
>
/>
>
>
>
namespace Clients
2: {
class Program
4: {
string[] args)
6: {
))
8: {
new List<IService>();
int i = 0; i < 10; i++)
11: {
12: channelList.Add(channelFactory.CreateChannel());
13: }
14:
15: Array.ForEach<IService>(channelList.ToArray<IService>(),
delegate(IService channel)
17: {
18: ThreadPool.QueueUserWorkItem(
delegate
20: {
21: channel.DoSomething();
, DateTime.Now);
null);
24: } );
25: Console.Read();
26: }
27: }
28: }
29: }
30:
首先通过ChannelFactory<IService> 先后创建了10个Proxy对象，然后以异步的方式进行service的调用（为了简单起见，直接通过ThreadPool实现异步调用），到service调用结束将当前时间输出来。我们来运行一下我们的程序，看看会出现怎样的现象。先来看看service端的输出结果：
![[原创]WCF后续之旅(12): 线程关联性（Thread Affinity）对WCF并发访问的影响](http://images.cnblogs.com/likecs_com/artech/WindowsLiveWriter/WCF12WCF_112BE/image_14.png "[原创]WCF后续之旅(12): 线程关联性（Thread Affinity）对WCF并发访问的影响")
通过上面的结果，从执行的时间来看service执行的并非并发，而是串行；从输出的线程ID更能说明这一点：所有的操作的执行都在同一个线程中，并且service执行的线程就是host service的UI线程。这充分证明了service的执行具有与service host的线程关联性。通过Server端的执行情况下，我们不难想象client端的执行情况。虽然我们是以异步的方式进行了10次service调用，但是由于service的执行并非并发执行，client的执行结果和同步下执行的情况并无二致：
![[原创]WCF后续之旅(12): 线程关联性（Thread Affinity）对WCF并发访问的影响](http://images.cnblogs.com/likecs_com/artech/WindowsLiveWriter/WCF12WCF_112BE/image_16.png "[原创]WCF后续之旅(12): 线程关联性（Thread Affinity）对WCF并发访问的影响")
二、解除线程的关联性
在本系列的上一篇文章，我们介绍了service的线程关联性通过ServiceBeahavior的UseSynchronizationContext控制。UseSynchronizationContext实际上代表的是是否使用预设的SynchronizationContext（实际上是DispatchRuntime的SynchronizationContext属性中制定的）。我们对service的代码进行如下简单的修改，使service执行过程中不再使用预设的SynchronizationContext。
namespace Artech.ThreadAffinity2.Services
2: {
false)]
class Service:IService
5: {
6:
//...
8: }
9: }
再次运行我们的程序，看看现在具有怎样的表现。首先看server端的输出结果：
![[原创]WCF后续之旅(12): 线程关联性（Thread Affinity）对WCF并发访问的影响](http://images.cnblogs.com/likecs_com/artech/WindowsLiveWriter/WCF12WCF_112BE/image_18.png "[原创]WCF后续之旅(12): 线程关联性（Thread Affinity）对WCF并发访问的影响")
我们可以看出，service的执行并不在service host的主线程下，因为Thread ID不一样，从时间上看，也可以看出它们是并发执行的。从Client的结果也可以证明这一点：
![[原创]WCF后续之旅(12): 线程关联性（Thread Affinity）对WCF并发访问的影响](http://images.cnblogs.com/likecs_com/artech/WindowsLiveWriter/WCF12WCF_112BE/image_20.png "[原创]WCF后续之旅(12): 线程关联性（Thread Affinity）对WCF并发访问的影响")
结论：当我们使用Windows Form Application进行service host的时候，首先应该考虑到在默认的情况下具有线程关联特性。你需要评估的service的整个操作是否真的需要依赖于当前UI线程，如果不需要或者只有部分操作需要，将UseSynchronizationContext 设成false，将会提高service处理的并发量。对于依赖于当前UI线程的部分操作，可以通过SynchronizationContext实现将操作Marshal到UI线程中处理，对于这种操作，应该尽力那个缩短执行的时间。
WCF后续之旅：
WCF后续之旅(1): WCF是如何通过Binding进行通信的
WCF后续之旅(2): 如何对Channel Layer进行扩展——创建自定义Channel
WCF后续之旅(3): WCF Service Mode Layer 的中枢—Dispatcher
WCF后续之旅(4)：WCF Extension Point 概览
WCF后续之旅(5): 通过WCF Extension实现Localization
WCF后续之旅(6): 通过WCF Extension实现Context信息的传递
WCF后续之旅(7)：通过WCF Extension实现和Enterprise Library Unity Container的集成
WCF后续之旅(8)：通过WCF Extension 实现与MS Enterprise Library Policy Injection Application Block 的集成
WCF后续之旅(9)：通过WCF的双向通信实现Session管理[Part I]
WCF后续之旅(9): 通过WCF双向通信实现Session管理[Part II]
WCF后续之旅(10): 通过WCF Extension实现以对象池的方式创建Service Instance
WCF后续之旅(11): 关于并发、回调的线程关联性（Thread Affinity）
WCF后续之旅(12): 线程关联性（Thread Affinity）对WCF并发访问的影响
WCF后续之旅(13): 创建一个简单的WCF SOAP Message拦截、转发工具[上篇]
WCF后续之旅(13)：创建一个简单的SOAP Message拦截、转发工具[下篇]
WCF后续之旅(14)：TCP端口共享
WCF后续之旅(15): 逻辑地址和物理地址
WCF后续之旅(16): 消息是如何分发到Endpoint的--消息筛选(Message Filter)
WCF后续之旅(17)：通过tcpTracer进行消息的路由