线程关联性（Thread Affinity）对WCF并发访问的影响

　　在WCF并发、回调的线程关联性（Thread Affinity）中, 我们重点讨论了线程关联性对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应用：

1、Contract:IService

namespace Artech.ThreadAffinity2.Contracts
{
    [ServiceContract]
    public interface IService
    {
        [OperationContract]
        void DoSomething();
    }
}
		

2、Service：Service

   1: namespace Artech.ThreadAffinity2.Services

   2: {

   3:     public class Service:IService

   4:     {

   5:         public static ListBox DispalyPanel

   6:         { get; set; } 

   7:  

   8:         public static SynchronizationContext SynchronizationContext

   9:         { get; set; } 

  10:  

  11:         #region IService Members 

  12:  

  13:         public void DoSomething()

  14:         {

  15:             Thread.Sleep(5000);

  16:             int threadID = Thread.CurrentThread.ManagedThreadId;

  17:             DateTime endTime = DateTime.Now;

  18:             SynchronizationContext.Post(delegate

  19:             {

  20:                 DispalyPanel.Items.Add(string.Format("Serice execution ended at {0}, Thread ID: {1}",

  21:                     endTime, threadID));

  22:             }, null);

  23:         } 

  24:  

  25:         #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：

   1: namespace Artech.ThreadAffinity2.Hosting

   2: {

   3:     public partial class HostForm : Form

   4:     {

   5:         private ServiceHost _serviceHost; 

   6:  

   7:         public HostForm()

   8:         {

   9:             InitializeComponent();

  10:         } 

  11:  

  12:         private void HostForm_Load(object sender, EventArgs e)

  13:         {

  14:             this.listBoxResult.Items.Add(string.Format("The ID of the Main Thread: {0}", Thread.CurrentThread.ManagedThreadId));

  15:             this._serviceHost = new ServiceHost(typeof(Service));

  16:             this._serviceHost.Opened += delegate

  17:             { 

  18:                 this.Text = "Service has been started up!";

  19:             };

  20:             Service.DispalyPanel = this.listBoxResult;

  21:             Service.SynchronizationContext = SynchronizationContext.Current;

  22:             this._serviceHost.Open();

  23:         } 

  24:  

  25:         private void HostForm_FormClosed(object sender, FormClosedEventArgs e)

  26:         {

  27:             this._serviceHost.Close();

  28:         }

  29:     }

  30: }

　　在HostForm_Load，先在ListBox中显示当前线程的ID，然后通过 Service.DispalyPanel和Service.SynchronizationContext 为service的执行设置LisBox和SynchronizationContext ，最后将servicehost打开。下面是Configuration：

   1: <?xml version="1.0" encoding="utf-8" ?>

   2: <configuration>

   3:     <system.serviceModel>

   4:         <services>

   5:             <service name="Artech.ThreadAffinity2.Services.Service">

   6:                 <endpoint binding="basicHttpBinding" contract="Artech.ThreadAffinity2.Contracts.IService" />

   7:                 <host>

   8:                     <baseAddresses>

   9:                         <add baseAddress="http://127.0.0.1/service" />

  10:                     </baseAddresses>

  11:                 </host>

  12:             </service>

  13:         </services>

  14:     </system.serviceModel>

  15: </configuration>

4、Client

我们通过一个Console Application来模拟client端程序，先看看configuration：

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <system.serviceModel>
        <client>
            <endpoint address="http://127.0.0.1/service" binding="basicHttpBinding"
                contract="Artech.ThreadAffinity2.Contracts.IService" name="service" />
        </client>
    </system.serviceModel>
</configuration>
		

下面是service调用的代码：

namespace Clients
{
    class Program
    {
        static void Main(string[] args)
        {
            using (ChannelFactory<IService> channelFactory = new ChannelFactory<IService>("service"))
            {
                IList<IService> channelList = new List<IService>();
                for (int i = 0; i < 10; i++)
                {
                    channelList.Add(channelFactory.CreateChannel());
                } 
  
                Array.ForEach<IService>(channelList.ToArray<IService>(), 
                    delegate(IService channel)
                { 
                    ThreadPool.QueueUserWorkItem(
                    delegate
                    {
                        channel.DoSomething();
                        Console.WriteLine("Service invocation ended at {0}", DateTime.Now);
                    }, null);
                } );
                Console.Read();
            }
        }
    }
} 
  
		

　　首先通过ChannelFactory<IService> 先后创建了10个Proxy对象，然后以异步的方式进行service的调用（为了简单起见，直接通过ThreadPool实现异步调用），到service调用结束将当前时间输出来。我们来运行一下我们的程序，看看会出现怎样的现象。先来看看service端的输出结果：

　　通过上面的结果，从执行的时间来看service执行的并非并发，而是串行；从输出的线程ID更能说明这一点：所有的操作的执行都在同一个线程中，并且service执行的线程就是host service的UI线程。这充分证明了service的执行具有与service host的线程关联性。通过Server端的执行情况下，我们不难想象client端的执行情况。虽然我们是以异步的方式进行了10次service调用，但是由于service的执行并非并发执行，client的执行结果和同步下执行的情况并无二致：

二、解除线程的关联性

　　在本系列的上一篇文章，我们介绍了service的线程关联性通过ServiceBeahavior的UseSynchronizationContext控制。UseSynchronizationContext实际上代表的是是否使用预设的SynchronizationContext（实际上是 DispatchRuntime的SynchronizationContext属性中制定的）。我们对service的代码进行如下简单的修改，使 service执行过程中不再使用预设的SynchronizationContext。

namespace Artech.ThreadAffinity2.Services
{
    [ServiceBehavior(UseSynchronizationContext = false)]    
    public class Service:IService
    {
  
         //...
    }
}
		

　　再次运行我们的程序，看看现在具有怎样的表现。首先看server端的输出结果：

　　我们可以看出，service的执行并不在service host的主线程下，因为Thread ID不一样，从时间上看，也可以看出它们是并发执行的。从Client的结果也可以证明这一点：

　　结论：当我们使用Windows Form Application进行service host的时候，首先应该考虑到在默认的情况下具有线程关联特性。你需要评估的service的整个操作是否真的需要依赖于当前UI线程，如果不需要或者只有部分操作需要，将UseSynchronizationContext 设成false，将会提高service处理的并发量。对于依赖于当前UI线程的部分操作，可以通过SynchronizationContext实现将操作Marshal到UI线程中处理，对于这种操作，应该尽力那个缩短执行的时间。

作者：Artech
出处：http://artech.cnblogs.com/

加支付宝好友偷能量挖...

2012-5-28评论(0)网络

阅读(131)喜欢(0)分类：Asp.Net/C#/WCF