使用 WCF 并发组合 InstanceContextMode=Single 和 ConcurrencyMode=Multiple 是否明智？答案

【问题标题】：is it ever sensible to use WCF concurrency combination InstanceContextMode=Single and ConcurrencyMode=Multiple?使用 WCF 并发组合 InstanceContextMode=Single 和 ConcurrencyMode=Multiple 是否明智？
【发布时间】：2012-03-12 05:47:39
【问题描述】：

如果我理解正确，您应该实施锁定以防止并发问题，从而失去多线程的所有好处。

下面的文章

http://www.codeproject.com/Articles/89858/WCF-Concurrency-Single-Multiple-and-Reentrant-and#Instance%20mode%20=%20Single%20and%20Concurrency%20=%20Multiple

用例子描述了这一点。但是我无法理解这是如何工作的，因为没有锁定。

感谢和最好的问候 - 马蒂

【问题讨论】：

关于您引用的文章要记住的一点是，它从使用控制台主机得出结论。虽然那篇文章对于控制台托管服务可能是准确的，甚至可能适用于 Windows 服务主机，但我非常不愿意将其中一些假设/结论转移到由 IIS/WAS 托管的 WCF 服务中。对于基于 IIS/WAS 的主机，很少有理由使用 InstanceContextMode Single（基本上是您的单例模式）。
感谢您的回答。我不太明白为什么它适用于控制台。如果线程 1 读取并且值增加它，并且线程 2 被安排在线程 1 写回它之前，那么增加（i++）实例变量不仅是一个可能的并发问题。那么线程 2 的增量就会丢失。
并不是代码不适用，只是 IIS 中的多线程环境更复杂，从控制台主机的性能驱动的假设可能不成立。 IIS 中的给定服务类型可能有多个 ServiceHost 实例，这在控制台或 Windows 服务托管中通常不是这种情况。在 IIS 托管环境中，服务的多线程单例实例不会为您提供比每次调用实例化和 ConcurrencyMode = Single 更好的可伸缩性，因为处理请求负载的是 IIS/WAS。
好的。我明白，但你能告诉我为什么我的评论中描述的场景（线程 2 的增量丢失）不会发生。

标签： .net multithreading wcf

【解决方案1】：

并发问题通常仅在您必须处理不断变化的状态时才会出现。如果您正在创建一个只提供数据而不负责处理状态更改的 Web 服务，那么此配置可能是一个不错的选择。

【讨论】：

【解决方案2】：

锁定不会导致您“失去多线程的所有好处”。

如果你这样写代码：

lock (shared_object) 
{
    // do everything here
    return value;
}

那么是的，您刚刚导致并发应用程序变得同步（并且浪费了等待锁定的线程）。但是您不必以这种方式编写代码以使其成为线程安全的。

通常，只有少数几个关键部分实际上需要锁定。例如，在您链接的文章中，“i”是唯一的共享变量，因此要使其线程安全，只需使用 var local_i = Interlocked.Increment(ref i);。

不过，这是一个微不足道的例子，所以它当然看起来就像你没有得到任何东西一样。在现实世界的场景中，您会做一些不需要同步的事情，并且会从并发中获益。

【讨论】：