博客园_bengxia-未来与荣耀

MY 2012 GOALS

2011-12-30T07:34:00Z

1. 每月读1本书；

2. 每天背20个单词；

3. 每周锻炼身体3次；

4. 每天练习口语40分钟；

5. 每月写5篇博客；

6. 每天写20+行代码。

本文链接

Silverlight + WCF + Sharepoint（Silverlight Web Part）问题集合

2011-12-28T08:22:00Z

“找不到类型{..} 它在 ServiceHost 指令中提供为 Service 特性值，或在配置元素 system.serviceModel/serviceHostingEnvironment/serviceActivations 中提供。”
- 　　确认.svc文件中的<%@ ServiceHost Language="C#" Debug="true" Service="{ServiceName}" CodeBehind="....cs" %>的{ServiceName}是不是跟Web.config中的服务名称一致。
“自定义工具警告: 没有找到与Silverlight 4 兼容的端点。生成的客户端类将不可用，除非通过构造函数提供端点信息。”
- 　　WCF是否启用了Silverlight支持？WCF有WCF服务，WCF数据服务，在Silverlight中还有启用Silverlight支持的WCF，靠。
- 　　[配置服务引用...]，取消选择[重新使用引用的程序集中的类型]。

发布到Sharepoint中的Silverlight调用外域的WCF服务

　　将添加WCF服务时生成的Reference.cs从Service References移动到项目文件夹下，可以重命名。

　　修改...Client代码：

EndpointAddress endPointAddress = new EndpointAddress("{wcf uri}");
            CustomBinding binding = new CustomBinding();
            binding.Elements.Add(new BinaryMessageEncodingBindingElement());
            binding.Elements.Add(new HttpTransportBindingElement());

            Adomd.AnalysisService.AdomdConnectorClient client = new Adomd.AnalysisService.AdomdConnectorClient(binding, endPointAddress);

注意：如果不使用CutomBinding而用BasicHttpBinding就会返回：Not Found错误，主要是协议的问题，这是跟踪HTTP请求时发现的。

　　在WCF宿主目录下（跟web.config一起）添加跨域策略文件clientaccesspolicy.xml：

<?xml version="1.0" encoding="utf-8" ?>
<access-policy>
    <cross-domain-access>
        <policy>
            <allow-from http-request-headers="*">
                <domain uri="*"/>
            </allow-from>
            <grant-to>
                <resource path="/" include-subpaths="true"/>
            </grant-to>
        </policy>
    </cross-domain-access>
</access-policy>

挖坑ing...

本文链接

CLR Via C# 3rd 阅读摘要 -- Chapter 29 – Hybrid Thread Synchronization Constructs

2010-07-02T06:53:00Z

A Simple Hybrid Lock

混合结构在没有竞争的情况下，提供了原生用户模式同步结构的性能优点。同时在有竞争的情况下，提供了核心模式同步结构不浪费CPU资源的优点；

SimpleHybridLock：

internal sealed class SimpleHybridLock : IDisposable {
     // The Int32 is used by the primitive user-mode constructs (Interlocked methods)
     private Int32 m_waiters = 0;
     // The AutoResetEvent is the primitive kernel-mode construct
     private AutoResetEvent m_waiterLock = new AutoResetEvent(false);
     public void Enter() {
     // Indicate that this thread wants the lock
     if (Interlocked.Increment(ref m_waiters) == 1)
     return; // Lock was free, no contention, just return
     // Another thread is waiting. There is contention, block this thread
     m_waiterLock.WaitOne(); // Bad performance hit here
     // When WaitOne returns, this thread now has the lock
     }
     public void Leave() {
     // This thread is releasing the lock
     if (Interlocked.Decrement(ref m_waiters) == 0)
     return; // No other threads are blocked, just return
     // Other threads are blocked, wake 1 of them
     m_waiterLock.Set(); // Bad performance hit here.
     }
     }

Spinning, Thread Ownership, and Recursion

AnotherHybridLock：

internal sealed class AnotherHybridLock : IDisposable {
     // The Int32 is used by the primitive user-mode constructs (Interlocked methods)
     private Int32 m_waiters = 0;
     // The AutoResetEvent is the primitive kernel-mode construct
     private AutoResetEvent m_waiterLock = new AutoResetEvent(false);
     // This field controls spinning in an effort to improve performance
     private Int32 m_spinCount = 4000; // Arbitrarily chosen count
     // These fields indicate which thread owns the lock and how many times it owns it
     private Int32 m_owningThreadId = 0, m_recursion = 0;
     public void Enter() {
     // If calling thread already owns the lock, increment recursion count and return
     Int32 threadId = Thread.CurrentThread.ManagedThreadId;
     if (threadId == m_owningThreadId) {
     m_recursion++;
     return;
     }
     // The calling thread doesn't own the lock, try to get it
     SpinWait spinwait = new SpinWait();
     for (Int32 spinCount = 0; spinCount < m_spinCount; spinCount++) {
     // If the lock was free, this thread got it; set some state and return
     if (Interlocked.CompareExchange(ref m_waiters, 1, 0) == 0)
     goto GotLock;
     // Black magic: give other threads a chance to run
     // in hopes that the lock will be released
     spinWait.SpinOnce();
     }
     // Spinning is over and the lock was still not obtained, try one more time
     if (Interlocked.Increment(ref m_waiters) > 1) {
     // Other threads are blocked and this thread must block too
     m_waiterLock.WaitOne(); // Wait for the lock; preformance hit
     // When this thread wakes, it owns the lock; set some state and return
     }
     GotLock:
     // When a thread gets the lock, we record its ID and
     // indicate that the thread owns the lock once
     m_owningThreadId = threadId;
     m_recursion = 1;
     }
     public void Leave() {
     // If the calling thread doesn't own the lock, there is a bug
     Int32 threadId = Thread.CurrentThread.ManagedThreadId;
     if (threadId != m_owningThreadId)
     throw new SynchronizationLockException("Lock not owned by calling thread");
     // Decrement the recursion count. If this thread still owns the lock, just return
     if (--m_recursion > 0)
     return;
     // If no other threads are blocked, just return
     if (Interlocked.Decrement(ref m_waiters) == 0)
     return;
     // Other threads are bloced, wake 1 of them
     m_waiterLock.Set(); // Bad performance hit here
     }
     }

性能比较参考：

Incrementing x: 8 Fastest
     Incrementing x in Mutex: 50 6x slower
     Incrementing x in SimpleSpinLock: 210 26x slower
     Incrementing x in SimpleHybridLock: 211 26x slower (similar to SimpleSpinLock)
     Incrementing x in AnotherHybridLock: 415	52x slower (due to ownership/recursion)
     Incrementing x in SimpleWaitLock: 17,615	2,201x slower

A Potpourri of Hybrid Constructs

System.Threading.ManualResetEventSlim，System.Threading.SemaphoreSlim：跟对应的ManualResetEvent, Semaphore很相似，不同点：直到第一次竞争出现，它们将轮转在用户模式并推迟创建内核模式同步结构；另外，Wait(Int32 millisecondsTimeout, CancellationToken cancellationToken)方法可以传入超时参数和CancellationToken；
Monitor(关键字lock，在JIT时会使用Monitor)，一个常用的混合模式同步结构类，提供了支持轮转、线程所有权、递归计数的互斥锁；
每个托管堆上的对象都有一个叫做“同步块(Sync Block)”的数据结构跟它相关联，该数据结构具备字段：内核对象、所属线程ID、递归计数、等待线程数量。
当CLR初始化时，会分配一个同步块数组。每个托管堆上的对象，都有两个开销字段：类型对象指针(Type Object Pointer)、同步块索引(Sync Block Index) -- 关联到系统同步块数组的索引(-1：不关联任何同步块)；
当Mointer.Enter方法被调用后，CLR会在数组中找到一个空闲的同步块，然后设置对象的同步块索引指向同步块。当Monitor.Exit被调用后，CLR会检查是否有其他线程在等待使用对象的同步块。如果没有，同步块被释放，对象的Sync Block Index被设置成-1；
同步块可以被关联到类型对象，类型对象的引用可以传递给Monitor的方法；
Monitor.Enter(this), .Exit(this)，这里会出现一个比较晦涩的BUG，this所代表的对象在外部可能会被作为锁，这样就不能正常工作，所以总是使用一个私有锁代替，
```
private readonly Object m_lock = new Object();
     ...
     Monitor.Enter(m_lock);
     ...
     Monitor.Exit(m_lock);
     
```
；
Monitor是一个静态类，所以存在一些问题需要注意：
- 如果对象的类型指向System.MarshalByRefObject类型的子类，一个变量可以引用到一个代理对象。当通过传递代理对象的引用调用Monitor的方法时，锁住的是代理对象，而不是实际对象；
- 如果一个线程调用Monitor.Enter时，传递一个以及域中立加载的类型对象的引用，线程给进程中所有AppDomain中的该类型上锁。这是一个BUG，所以绝不使用类型对象的引用调用Monitor的方法；
- 因为Monitor的方法使用Object做参数，所以传递一个值类型会引起装箱操作。这样锁住的是装箱之后的对象，所以一切同步都白搭；
- 使用[MethodImpl(MethodImplOptions.Synchronized)]属性到一个方法上，会引起JIT编译器使用Monitor.Enter和Monitor.Exit包转在本地代码上，如果该方法是个实例方法，那么this就是Monitor方法的参数，锁住的是隐式的公共锁(可能是个噩梦)。如果该方法是静态方法，那么类型的类型对象就是Monitor方法的参数，那就噩梦连绵了。所以，绝不要使用在方法上使用[MethodImpl(MethodImplOptions.Synchronized)]属性
- 当调用类型的类型构造器(静态构造器)，CLR在类型的类型对象上加锁以确定只有一个线程初始化该类型对象和它的静态字段。建议：尽可能的避免类型构造器，或者保证它短小精干。
lock会引入Monitor和try/finally块，而JIT不会内联编译带有try块的方法，这会导致降低性能。所以一般不推荐使用lock关键字；
ReaderWriterLockSlim, OneManyLock, CountdownEvent, Barrier, ...
建议写代码时，别阻塞所有的线程，尽可能短的持有锁；
读写锁通常比Monitor要慢，但是允许多个读线程并发执行，改善了整体性能，同时最小化了线程阻塞的可能；
避免使用递归锁(特别是读写递归锁)，因为太糟蹋性能了；
避免在finally中释放锁，因为进入和离开异常处理块会有性能负担。尤其是在改变状态时出现了异常，那么会导致无法预知的行为，并出现安全漏洞；
面向计算方向的工作，还是使用task；
面向I/O方向的工作，采用APM在I/O操作完成后调用回调方法；
可以使用SpinLock代替Monitor因为SpinLock稍微快一点，但是SpinLock可能会浪费CPU。Monitor实际上也挺快，因为使用本地代码实现的，而不是托管代码；

The Famous Double-Check Locking Technique

延迟初始化，单例对象知道应用程序使用它才开始初始化，节约时间和内存。潜在问题会出现在当多个线程同时首次访问该对象时；
The "Double-Checked Locking is Broken" Declaration

不幸的Java两次检查锁单例代码，如果编译器进行优化或者共享内存的多处理器环境下，下面的代码不会正常工作，原因有一大箩筐。

// Broken multithreaded version
     // "Double-Checked Locking" idiom
     class Foo {
     private Helper helper = null;
     public Helper getHelper() {
     if (helper == null)
     synchronized(this) {
     if (helper == null)
     helper = new Helper();
     }
     return helper;
     }
     // other functions and members...
     }

简单的办法，使用静态字段：

class HelperSingleton {
     static Helper singleton = new Helper();
     }

或者，使用JDK5的新语法,volatile关键字:

// Works with acquire/release semantics for volatile
     // Broken under current semantics for volatile
     class Foo {
     private volatile Helper helper = null;
     public Helper getHelper() {
     if (helper == null) {
     synchronized(this) {
     if (helper == null)
     helper = new Helper();
     }
     }
     return helper;
     }
     }

CLR支持Double-Checked Locking，C#版：

internal sealed class Singleton {
     private static readonly Object s_lock = new Object();
     private static Singleton s_value = null;
     private Singleton() {
     }
     public static Singleton GetSingleton() {
     if (s_value != null) return s_value;
     Monitor.Enter(s_lock);
     if (s_value == null) {
     Singleton temp = new Singleton();
     Interlocked.Exchange(ref s_value, temp);
     }
     Monitor.Exit(s_lock);
     return s_value;
     }
     }

其实，这才是最实用的单例模式：
```
internal sealed class Singleton {
     private static Singleton s_value = new Singleton();
     private Singleton() {
     }
     public static Singleton GetSingleton() { return s_value; }
     }
```
因为CLR在代码第一次尝试访问类的成员时，会自动调用类型的类构造器(class initializer, type initializer, static initializer)。线程第一次调用Singleton.GetSingletonk静态方法时，CLR自动调用类构造器(注意Before-Field-Init语义)，创建出一个该对象的实例。并且：CLR保证调用类型构造器是线程安全的。

上面的代码有一点点遗憾，如果Singleton中有其他静态成员，如果任何一个被访问时，Singleton对象就会被创建，这可能并不是所想要的。那么下面的代码简单实用高效可靠：

internal sealed class Singleton {
     private static Singleton s_value = null;
     private Singleton() {
     }
     public static Singleton GetSingleton() {
     if (s_value != null) return s_value;
     Singleton temp = new Singleton();
     Interlocked.CompareExchange(ref s_value, temp, null);
     return s_value;
     }
     }

System.Lazy，System.Threading.LazyInitializer的静态方法，延迟加载和延迟初始化。

The Condition Variable Pattern

当满足一组复杂的条件时，线程执行特定的代码，否则不停轮转检测条件，这通常会浪费CPU时间，条件变量模式(condition variable pattern)可以基于复杂条件有效的进行同步操作；

简单的条件变量模式例子：

internal sealed class ConditionVariablePattern {
     private readonly Object m_lock = new Object();
     private Boolean m_condition = false;
     public void Thread1() {
     Monitor.Enter(m_lock);
     while (!m_condition) {
     Monitor.Wait(m_lock);
     }
     Monitor.Exit(m_lock);
     }
     public void Thread2() {
     Monitor.Enter(m_lock);
     m_condition = true;
     Monitor.PulseAll(m_lock);
     Monitor.Exit(m_lock);
     }
     }

线程安全的队列：

internal sealed class SynchronizedQueue<T> {
     private readonly Object m_lock = new Object();
     private readonly Queue<T> m_queue = new Queue<T>();
     public void Enqueue(T item) {
     Monitor.Enter(m_lock);
     m_queue.Enqueue(item);
     // After enqueuing an item, wake up any/all waiters;
     Monitor.PulseAll(m_lock);
     Monitor.Exit(m_lock);
     }
     public T Dequeue() {
     Monitor.Enter(m_lock);
     while (m_queue.Count == 0)
     Monitor.Wait(lock);
     T item = m_queue.Dequeue();
     Monitor.Exit(m_lock);
     return item;
     }
     }

Using Collections to Aviod Holding a Lock for a Long Time

System.Threading.Tasks所提供的往往更适合，为什么呢，比如Task：

比线程使用更少的内存，创建和销毁的时间更短；

线程池会根据CPU的情况自动扩容或收缩；

Task完成一个阶段，执行Task的线程回到线程池，然后线程可以干点其他的事；

线程池是全局进程可见的，可以更好的调度任务，减少进程中的线程数，同时减少线程上下文切换的开销。

Reader-Writer锁非常有用。Power Threading库有个非阻塞的读写类ReaderWriterGate。

The Concurrent Collection Classes

FCL提供了4个线程安全的集合类型：System.Collections.Concurrent's (ConcurrentQueue, ConcurrentStack, ConcurrentDictionary)(MSCorLib.DLL), ConcurrentBag(System.DLL)；

ConcurrentDictionary内部使用Monitor；

ConcurrentQueue, ConcurrentStack没有锁，内部使用Interlocked方法来维护集合；

ConcurrentBag内部由每个线程一个迷你集合容器组成；

ConcurrentStack, ConcurrentQueue, ConcurrentBag, .GetEnumerator方法返回集合内容的快照；

ConcurrentDictionary.GetEnumerator方法不是返回内容的快照，要注意在枚举的过程中元素状态会发生改变。

本章小结

本章讲述的是混合的线程同步模式，首先通过一个简单的例子演示了如何混合使用用户模式和核心模式的同步结构。然后说明了轮转、线程所有制、锁递归的概念。接着列举了几种混合同步结构的实例，并进行了分析比较。本章还讨论了一个非常有意思的问题：单例模式的两次检查加锁情况，给出了正确实现单例模式的方法。然后讲了什么是条件变量模式，以及如何通过使用集合、Task和线程池来避免长时间持有锁。最后简单说明了四个并发集合类。

本文链接

CLR Via C# 3rd 阅读摘要 -- Chapter 28 – Primitive Thread Synchronization Constructs

2010-07-01T02:55:00Z

Class Libraries and Thread Safety

线程同步是用来避免多个线程同时访问共享数据时出现冲突；

线程同步的障碍：

1.极其乏味易错；

2.锁严重影响性能；

3.线程同步锁在同一时间点仅允许一个线程访问资源。

设计程序时应该尽可能的避免线程同步，最好避免采用static字段的共享数据；

尝试使用值类型，因为它们总是拷贝传递的，因此每个线程在自身拥有的拷贝上操作。所以当多个线程同时以只读方式访问值类型共享数据时是安全的。

FCL保证所有的静态方法是线程安全的；

当一个线程构造一个对象，只有该线程拥有该对象的引用，其他线程不能访问该对象；

类型设计时应遵循的模式：确保所有的静态方法多线程安全、所有的实例方法多线程不安全；
一个例外：如果实例方法是用于协调多线程的，那么该实例方法也应该多线程安全。如CancellationTokenSource.Cancel方法。

Primitive User-Mode and Kernel-Mode Constructs

两种原生线程同步结构：

用户模式：速度很快，使用特定的CPU指令协调线程，协调工作由硬件完成。Windows系统不会检测线程是否阻塞在用户模式同步结构；
线程池线程阻塞在用户模式同步结构不会被当成阻塞，线程池不会创建新的线程来代替临时阻塞的线程。
采用该模式的线程会被系统抢占调度，可能导致线程被反复快速调度，从而会浪费CPU；

核心模式：Windows操作系统提供，调用实现在系统内核的函数。当一个线程使用内核模式同步结构来请求其他线程持有的资源，Windows将阻塞该线程所以不会浪费CPU；
线程在用户模式与核心模式间互相转换会严重损害性能；

如果一个线程持有一个同步结构不再释放它，等待该结构的线程将永远被阻塞：

活锁：如果该同步结构是用户模式，线程一直运行在CPU上；

死锁：如果该同步结构是核心模式，线程被阻塞住；

活锁与死锁都很糟糕，但相比之下，活锁更糟糕，因为活锁既浪费CPU又浪费内存，而死锁只浪费内存；

User-Mode Constructs

原生的用户模式结构：
- 易变(volatile)结构：在一个简单数据类型变量上执行原子读或写操作；
- 联锁(Interlocked)结构：在一个简单数据类型变量上执行原子读和写操作；
易变结构确认读或写操作是否原子的非常重要，它们还控制这些原子操作的时机。联锁结构执行操作要比简单的读和写操作复杂一些，它们也需要控制操作的时机；
比如一个Int64的变量如果没有正确对齐，那么当多线程读写该变量时，可能会出现只正确读取前四字节或后四字节，这就是脏读(torn read)？
System.Threading.Thread.VolatileWrite(), .VolatileRead(), .MemoryBarrier()静态方法通常禁止C#编译器、JIT编译器、CPU进行优化；
当线程通过共享数据进行通信时，对最后一个值的写操作调用VolatileWrite()，对第一个值的读操作调用VolatileRead()；
C# volatile关键字：JIT编译器会对标记为volatile的字段的读写进行VolatileWrite()和VolatileRead()处理；
将来，C#不支持通过引用传递volatile字段到方法调用中；
现在，Interlocked.Exchange(), .CompareExchange()只支持简单值类型，将来还会提供对Object, IntPtr, Single, Double以及泛型版本的支持；

SimpleSpinLock的缺陷，当锁出现竞争时，线程会不停轮转，浪费CPU资源：

internal struct SimpleSpinLock {
    private Int32 m_ResourceInUse;  //0 = false (default), 1 = true
    
    public void Enter() {
        // Set the resource to in-use and if this thread
        // changed it from Free, then return
        while (Interlocked.Exchange(ref m_ResourceInUse, 1) != 0) {
            // Black Magic goes here...
        }
    }
    
    public void Leave() {
        // Mark the resource as Free
        Thread.VolatileWrite(ref m_ResourceInUse, 0);
    }
}

FCL提供的System.Threading.SpinWait；
Thread.Sleep(),允许线程资源放弃时间片，休眠时间是近似值；
Thread.Yield(),告诉Windows在当前CPU上调度其他线程。如果当前CPU上有其他线程，返回true并结束调用线程的时间片，被调度线程结束自身的时间片之后，调用线程继续。
Thead.SpinWait(),线程强制自己暂停，允许超线程CPU切换到其他线程。该方法会使用特别的CPU指令，如果CPU不支持超线程，该指令被忽略；
Win32 API：Sleep(), SwitchToThread(), YieldProcessor()；
当集合中的每一项都需要关联锁的时候，轻量级、内存友好的SpinLock是个好东西。但是要注意不要传递它的实例，因为是值类型，传递的是拷贝；

Kernel-Mode Constructs

核心模式的同步结构比用户模式的要慢许多，因为它们由Windows操作系统协调，此外每个核心对象上的方法调用都会导致调用线程从托管代码转换到本地用户模式代码再到本地核心模式代码，然后再原路返回；
核心模式同步结构提供哪些用户模式所没有的优点：
- 当核心模式同步结构检测到资源上出现竞争时，Windows阻塞竞争失败的线程，因此不再浪费处理器资源；
- 核心模式同步结构可以同步本地线程和托管线程；
- 核心模式同步结构可以同步运行在同一台机器上不同处理器上的线程；
- 核心模式同步结构可以附上安全限制避免未经认证的帐号访问他们；
- 线程能够被阻塞直到所有的核心模式同步结构都可用，或者任何一个可用；
- 阻塞在核心模式同步结构上的线程可以设置一个timeout值；如果这段时间内没能获得期望的资源，那么不再阻塞以干点其他正事。
原生的核心模式结构：
- 事件(Events)：事件是有内核管理的Boolean变量。当事件为false时，线程被阻塞。有两种事件：AutoResetEvent、ManualResetEvent；
- 信号量(Semaphore)：信号量是内核管理的Int32变量。当信号量为0时，线程被阻塞；>0时，线程不被阻塞。

核心模式结构的层次结构：

WaitHandle
  |--EventWaitHandle
  |--|--AutoResetEvent
  |--|--ManualResetEvent
  |--Semaphore
  |--Mutex

每个在核心模式同步结构上的方法调用都会出现完全内存保护；
SimpleWaitLock vs SimpleSpinLock：
当锁上没有竞争时，SimpleWaitLock比SimpleSpinLock要慢许多，因为SimpleWaitLock的Enter和Leave方法会强制调用线程在托管代码到核心代码之间进行来回转换；
但是当锁上有竞争时，SimpleWaitLock不会浪费CPU资源，而SimpleSpinLock会不停的轮转CPU；
AutoResetEvent、ManualResetEvent、Semaphore行为比较：
- 当多个线程在AutoResetEvent上等待时，设置事件只会让一个线程不再被阻塞；
- 当多个线程在ManualResetEvent上等待时，设置事件会让所有线程不再被阻塞；
- 当多个线程在Semaphore上等待时，释放信号量会让releaseCount个线程不再被阻塞(relaseCount是Semaphore.Release()方法的参数)。
互斥体(Mutex)表现为一个同斥锁；
Mutex很像AutoResetEvent或者Semaphore(count = 1)，但有一些更复杂的逻辑：
- 首先，Mutex对象通过查询调用线程的ID记录了哪个线程获得了它。当线程调用ReleaseMutex，Mutex会确认是否为同一线程；
- 其次，Mutex维护一个递归计数指出被获得了多少次。只有当递归计数降为0时，其他线程才能获取。
Mutex对象需要更多的内存，并且需要维护额外信息，所以会比较慢；
如何当一个单独的核心结构可用时调用方法？使用System.Threading.ThreadPool.RegisterWaitForSingleObject静态方法。

本章小结

本章讲述了原生的线程同步结构，首先介绍了类库和线程安全性概念，然后对线程同步模式进行了分类：用户模式与核心模式，接着详细说明了这两种同步模式的实现细节，并举例进行了对比。
本文链接

FIX: Unable to find a version of the runtime to run this application.

2010-07-01T01:06:00Z

1. [发现问题] 安装Articulate Presenter '09之后，打开时报错：Unable to find a version of the runtime to run this application. 错误标题是：.Net Framework Initialization Error。

2. [分析问题] 从错误提示来看，应该是.NET CLR版本兼容性的问题，我的机器上安装了VS2010，所以CLR应该是v4。而系统是Windows 7 64bit，应该自带了CLR v2，Presenter ’09可能不支持v4使用Visual Studio 2010 SDK的命令：ClrVer.exe验证了一下：

D:\Program Files (x86)\Microsoft Visual Studio 10.0\VC>clrver Versions installed on the machine:

v2.0.50727

v4.0.30319

3. [解决问题] 解决问题出人意料的顺利：在目标文件Presenter.exe所在的目录新建配置文件Presenter.exe.config：

<configuration>
<startup>
<supportedRuntime version="v2.0.50727"/>
</startup>
</configuration>

本文链接

CLR Via C# 3rd 阅读摘要 -- Chapter 27 – I/O-Bound Asynchronous Operations

2010-06-22T07:28:00Z

How Windows Performs I/O Operations

Windows如何处理同步I/O操作？

IRP：I/O Request Packet；

当硬件设备执行I/O操作时，发出I/O请求的线程无事可做，Windows会让该线程休眠所以并不会浪费CPU；

Windows如何处理异步I/O操作？

.NET异步文件I/O，注意要有FileOptions.Asynchronous，然后调用BeginRead()；

完成的IRP从线程池中使用FIFO算法抽取；

当线程完成它的工作并返回到线程池中，线程池不会让它马上处理新的工作项直到CPUs再次饱和之后，因此减少了上下文切换而改进了性能。如果线程池稍后确定拥有的线程比实际需要的多，它会让这些多余的线程自行终结，回收这些线程占有的资源；

在CLR内部，线程池使用Windows资源I/O Completion Ports来实现异步I/O行为；

SilverLight版本的FCL没有提供同步I/O操作，因为在浏览器进程中运行的缘故。

The CLR's Asynchronous Programming Model(APM)

FCL中支持的APM的类型：

所有和硬件设备通讯的继承自System.IO.Stream的提供BeginWrite()和BeginRead()方法的类型；注意那些继承自System.IO.Stream但是不跟硬件设备通讯的类型，比如MemoryStream等，也提供了适合APM的BeginWrite()和BeginRead()方法，但是这些方法执行的是计算相关的操作，而不是I/O相关的操作，因此需要请求一个线程来执行计算相关的操作，而I/O相关的操作要少一个线程；

System.Net.Dns提供了BeginGetHostAddress(), BeginGetHostByName(), BeginGetHostEntry(), BeginResolve()；

System.Net.Sockets.Socket类提供BeginAccept(), BeginConnect(), BeginDisconnect(), BeginReceive(), BeginReceiveFrom(), BeginReceiveMessageFrom(), BeginSend(), BeginSendFile(), BeginSendTo()；

所有继承自System.Net.WebRequest的类型，提供了BeginGetRequestStream(), BeginGetResponse()方法；

Sytem.IO.Ports.SerialPort有一个只读属性BaseStream，有BeginRead()和BeginWrite()方法；

System.Data.SqlClient.SqlCommand类提供了BeginExecuteQuery(), BeginExecuteReader(), BeginExecuteXmlReader()。

每个BeginXxx()方法都有两个额外的参数:userCallback(:AsyncCallback委托类型)、stateObject(任何希望发送到userCallback的对象引用，在回调函数中，通过参数(IAsyncResult接口)的只读属性AsyncState来获得)；

当调用BeginXxx()方法时，首先构造出一个唯一的对象标识出I/O请求，然后将该I/O请求加入到Windows设备驱动的队列中，接着返回一个IAsyncResult对象的引用。可以把这个对象看成是你异步调用的凭据。

The AsyncEnumerator Class

APM的麻烦之处：

必须分隔代码到多个回调方法中；

必须避免使用参数和本地变量，因为这些变量没有分配在栈空间上，所以不能被其他线程和方法访问；

有些C#的代码结构中，比如try/catch/finally, using, for, do, while, foreach不能被使用；

有些特性比较难以实现，比如协调多个并发操作，支持取消和超时，通知GUI线程刷新控件等。

AsyncEnumerator可以解决这些APM的麻烦，提供的特性有：

和现有的.NET技术简便集成；

协调多个异步并发操作；

支持分组取消；

通过调用每个操作的EndXxx()方法自动取消一组异步操作，如果不关心结果的话；

从烦心应用程序的线程模型中解放出来；

异常处理支持；

调试支持。

The APM and Exceptions

HTTP(RFC 2616)申明客户端应用最多同时两个并发线程连接服务器。但是现在很多浏览器和服务器已经没有这个限制了；

如何在设计服务器程序时解除两个并发线程同时连接的限制：调整System.Net.ServicePointManager.DefaultConnectionLimit属性。

Applications and Their Threading Models

GUI程序只允许创建窗体的线程更新界面控件；

当线程池线程开始处理客户端请求，可以假设客户端的文化特性，允许Web服务器返回文化特定的数字、日期、时间等；

通过查询GUI线程的.SynchronizationContext.Current属性，可以获得一个SynchronizationContext的引用，可以将该引用保存在共享变量中。这样无论什么时候需要GUI线程修改UI时，就可以让线程池线程引用保存的对象并调用Post方法，将该引用通过将要被GUI线程激发的方法。

推荐使用Post(内部BeginInvoke())方法，它将回调压入到GUI线程的队列并允许线程池线程立即返回。而Send内部Invoke()方法，不会立即返回，会被阻塞；

ASP.NET Web窗体和XML Web服务程序，处理客户端请求开始运行的线程，会有一个继承自SynchronzationContext的对象跟它相关联。

Implementing a Server Asynchronously

如何实现异步的ASP.NET Web窗体页面，在.aspx文件的头部加入Page指示"Async=true"。然后在代码中调用AddOnPreRenderCompleteAsync方法；

如何实现异步的ASP.NET Web服务，提供两个方法BeginXxx(),EndXxx()，并加上属性标签[WebMethod]；

如何实现异步的WCF Web服务，定义符合模式的BeginXxx(), EndXxx()方法，然后用[OperationContract(AsyncPattern=true)]属性标签标记BeginXxx()。

The APM and Compute-Bound Operations

I/O请求会压入到Windows设备驱动的队列中。然而，委托的BeingInvoke方法通过内部调用TheadPool.QueueUserWorkItem()将计算方向的操作压入到CLR的线程池队列。

APM Considerations

APM要注意的问题：

不通过线程池使用APM；
APM提供三种途径来知晓异步操作是否完成：
线程在操作完成之前传入IAsyncResult对象调用EndXxx()；

一个线程可以被阻塞等待其他操作完成，通过调用WaitOne()(IAsyncResult.AsyncWaitHandle)；

线程可以连续的查询IAsyncResult.IsCompleted属性。

总是调用EndXxx()方法，并只调用一次。否则会有资源泄露；
要求调用EndXxx()有两个原因：
当你初始化一个异步操作时CLR会分配一些内部资源。当操作完成后，CLR会持有这些资源知道EndXxx()被调用；

当初始化一个异步操作，你实际上并不知道该操作最终是成功还是失败。发现问题的唯一途径是调用EndXxx()查询返回值或者检查异常。

调用EndXxx()方法时总是使用同样的对象；
当调用BeginInvoke时，IAsyncResult对象内部会持有一个引用到最初对象。

在调用BeginXxx()和EndXxx()方法时使用ref, out和params参数；

不能取消一个异步的I/O方向的操作；

内存消耗：如果你知道所要执行的I/O操作能够很快完成，那么以同步方式执行更合适；

有些I/O操作必须以同步方式完成。比如Win32的CreateFile(调用FileStream的构造器)总是以同步方式执行；
Windows Vista，微软引入了新的Win32函数CancelSynchronousIO()。该函数允许线程取消一个被其他线程执行的同步I/O操作。
Windows没有提供异步访问注册表、访问系统事件日志、获得目录/子目录、修改文件/目录的属性、……的函数。

FileStream特定的问题。
FileOptions.Asynchronous标志(等效于Win32的CreateFile的FILE_FLAG_OVERLAPPED标志)：如果没有指定该标志，Windows以同步方式执行所有的文件操作。当然，仍然可以调用FileStream.BeginRead()方法，看上去操作以异步方式执行，但在内部，FileStream使用另外的线程来模拟异步操作。
当使用FileStream，必须确定是以同步还是异步方式执行，也就是FileOptions.Asynchronous标志。如果指定该标志，总是调用BeginRead()，如果不指定，总是调用Read()。

I/O Request Priorities

低优先级的线程获得时间后，可以在短时间内排队大量的I/O请求，所以呢低优先级的线程可能会挂起高优先级的线程，从而严重影响系统的响应性；

关于I/O优先级，可以从这里下载I/O Prioritization in Windows Vista白皮书；

相关的Win32 API：GetCurrentProcess、GetCurrentThread、CancelSynchronousIo；

进程只能影响他自己的后台处理模式；Windows不允许线程修改其他进程的后台处理模式；

优先级反转：低优先级的线程在正常优先级的线程等待时抢得了线程同步锁，正常优先级的线程可能最终等待后台优先级的线程直到低优先级I/O请求完成。

Converting the IAsyncResult APM to a Task

I/O-Bound 从APM转换到Task：
APM 代码片段：

WebRequest webRequest = WebRequest.Create("http://wintellect.com");
     webRequest.BeginGetResponse(result => {
     WebResponse webResponse = null;
     try {
     webResponse = webRequest.EndGetRespone(result);
     Console.WriteLine("Content Length: " + webResponse.ContentLength);
     }
     catch (WebException we) {
     Console.WriteLine("Failed: " + we.GetBaseException().Message);
     }
     finally {
     if (webResponse != null) webResponse.Close();
     }
     }, null);

Task 代码片段：

WebRequest webRequest = WebRequest.Create("http://wintellect.com");
     Task.Factory.FromAsync<WebResponse>(
     webRequest.BeginGetResponse, webRequest.EndGetRespone, null, TaskCreationOptions.None)
     .ContinueWith(task => {
     WebResponse webResponse = null;
     try {
     webResponse = task.Result;
     Console.WriteLine("Content Length: " + webResponse.ContentLength);
     }
     catch (AggregateException ae) {
     if (ae.GetBaseException() is WebException)
     Console.WriteLine("Failed: " + ae.GetBaseException().Message);
     else
     throw;
     }
     finally {
     if (webResponse != null) webResponse.Close();
     }
     });

The Event-Based Asynchronous Pattern

EAP：Event-based Asynchronous Pattern；

BackgroundWorker是设计用来处理计算方向的异步工作的，别错误的用来完成I/O方向的异步工作。I/O方向的比计算方向的异步操作可以少一个线程；

BackgroundWorker提供三个(EAP)事件：DoWork、ProgressChanged、RunWorkerCompleted；

将EAP转换成Task：System.Threading.Tasks.TaskCompletionSource；

比较APM和EAP：

EAP比APM最大的优点就是Visual Studiao设计时支持。GUI程序，事件处理方法由GUI线程激发；

EAP内部以APM方式实现，需要更多的内存并且执行速度相对较慢。实际上，EAP必须为所有的过程报告和完成事件分配多个继承自EventArg的对象；

以后，静态方法和单例类不再能提供EAP，因为：程序的不同部分可以立刻注册所有的事件，当操作完成时，程序的不同部分无论是否异步操作都需要激发事件处理方法；

EAP一般用于窗体程序，而且由于有额外开销，虽然在设计器上可以方便使用，但是还是不建议使用。

Programming Model Soup

比较：QueueUserWorkItem、Timer、RegisterWaitForSingleObject、Tasks、IAsyncResult APM、Event-based PM、AsyncEnumerator；

Tasks比QueueUserWorkItem或委托的BeginInvoke性能更好；

对于ThreadPool.QueueUserWorkItem或委托的BeginInvoke，使用PreFairness标志可以获得相同的线程池行为；

可以定制TaskScheduler，可以改变调度算法而不需要改变代码或编程模型；

Task对象比QueueUserWorkItem或委托的BeginInvoke会消费更多的内存；

IAsyncResult APM提供了四种技术，模型比较复杂，但是如果少使用回调方法技术，模型就简单多了；

支持EAP的类多半都支持取消我行为；

IAsyncResult APM支持不支持任何取消操作；

EAP是基于事件的，因此可以简单的用于Windows窗体、WPF、SilverLight窗体设计器。

本章小结

本章详细讲述了I/O方向的异步工作如何完成，首先解释了Windows处理同步I/O和异步I/O的内部机制。然后介绍了APM，针对APM的问题还介绍了一个Wintellect的辅助类AsyncEnumerator。接着讲了APM如何处理异常，以及应用程序如何选择线程模型。演示了如何实现一个异步的服务器程序(ASP.NET WEB服务、ASP.NET窗体页面、WCF)。解释了APM还可以用于计算方向的异步操作。接着，重点解释了APM的缺点以及处理办法。然后讲述了I/O请求的优先级，以及如何讲了IAsyncResult APM转换成Task。接着还介绍了一种不太优雅的异步编程模型EAP。最后针对几种异步编程模型进行了比较。

本文链接

CLR Via C# 3rd 阅读摘要 -- Chapter 26 – Compute-Bound Asynchronous Operations

2010-06-09T03:39:00Z

Introducing the CLR's Thread Pool

线程池可以看成有一组线程可以被你的应用程序以自有的方式使用；

每个CLR有一个线程池，这个线程池被该CLR控制的AppDomain共享；

当CLR初始化时，线程池中没有线程。线程池内部维护一个操作请求的队列；

线程池最重要的作用是管理拥有多少线程才算合适，少点线程以避免浪费资源，多点线程以发挥多处理器、超线程处理器、多核处理器的优势；

工作者线程(Worker Threads)用来当应用程序请求线程池来执行异步的计算方向的操作(也可以初始化一个I/O方向的操作)；

I/O线程(I/O Threads)用来通知你的代码一个异步的I/O操作已经完成；

APM：Asynchronous Programming Model。

Performing a Simple Compute-Bound Operation

TheadPool.QueueUserWorkerItem(WaitCallback callback), .QueueUserWorkerItem(WaitCallback callback, Object state)；

如果回调方法抛出一个异常没有被处理，CLR终止该进程(除非宿主强制使用自己的策略)。

Execution Contexts

每个线程都有一个相关联的执行上下文(Execution Context)数据结构，包括如安全设置(Thread.Principal)、宿主设置(System.Threading.HostExecutionContextManager)、逻辑调用上下文数据(Sytem.Runtime.Remoting.Messaging.CallContext.LogicalSetData(). LogicalSetData())；

ExecutionContext类允许你控制一个线程的Execution Context从一个线程产生自另一个线程；

ExecutionContext.SuppressFlow()方法标记有[SecurityCritical]属性，因此一些客户程序(比如SilverLight)不能调用；

流转包含逻辑调用上下文数据项的执行上下文会戏剧性的影响性能，因为需要序列化/反序列化这些数据项；

在执行ExecutionContext.SuppressFlow()之后，CallContext.LogicalSetData()设置的上下文数据就不能被访问了。

Cooperative Cancellation

合作取消模式，意味着你希望取消的操作必须支持显示的取消行为；

要在线程池中取消一个操作，必须使用System.Threading.CancellationTokenSource对象。实例化CancellationTokenSource对象后，该实例有一个Token属性；

可以注册(CancellationToken.Register())一个或多个方法，当一个CancellationTokenSource取消后被调用；

如何连接多个CancellationTokenSource对象，调用CancellationTokenSource.CreateLinkedTokenSource()静态方法。

Tasks

使用ThreadPool.QueueUserWorkerItem()虽然简单，但是有限制，最大的问题是不知道何时操作完成，也没有办法获得返回值；

更好的解决方案是使用Tasks，System.Threading.Tasks；

[Flags]public enum TaskCreationOptions {None, PreferFairness, LongRunning, AttachedToParent}；

等待一个Task完成并获得返回结果：Task.Wait()实例方法, Task.Result属性；

如果调用了Wait()，但是Task没有开始执行，系统可能(依赖TaskScheduler)使用调用Wait()的线程执行该Task，这样线程调用Wait()不会被阻塞；立即执行Task然后立即返回，这可能会节约资源提高性能，但是可能会造成死锁；

使用TaskScheduler.UnobservedTaskException静态事件注册回调方法，可以帮组检测未观测到的异常；

Task.WaitAny()静态方法阻塞调用线程直到数组中的任何Task对象完成；

Task.WaitAll()静态方法阻塞调用线程直到数组中的所有Task对象完成；

取消一个Task：Token.ThrowIfCancellationRequested();

如果CancellationToken在Task开始之后被调度之前取消，Task不执行就取消。但是如果不开始就取消，会抛出InvalidOperationException异常；

一旦一个Task对象有CancellationToken关联上，就没有途径访问它，所以你必须以某种方式获得相同的CancellationToken；

当一个Task完成时自动开始另一个Task：Task.ContinueWith()实例方法；

[Flags]public enum TaskContinuationOptions {None, PreferFairness, LongRunning, AttachedToParent, ExecuteSynchronously, NotOnRanToCompletion, NotOnFaulted, NotOnCanceled, OnlyOnCanceled, OnlyOnFaulted, OnlyOnRanToCompletion}；

一个Task开始多个Child Tasks：Task ；

public enum TaskStatus {Created, WaitingForActivation, WaitingToRun, Running, WaitingForChildrenToComplete, RanToCompletion, Canceled, Faulted};

TaskFactory , .StartNew()；

两类TaskScheduler：

线程池任务调度器：默认情况下，所有的应用程序使用线程池任务调度器；

同步上下文任务调度器：通常用于Windows Forms、WPF、SilverLight等GUI应用；

Parallel Extensions Extras包：

IOTaskScheduler

LimitedConcurrencyLevelTaskScheduler

OrderedTaskScheduler

PrioritizingTaskScheduler

ThreadPerTaskScheduler

Parallel's Static For, ForEach, and Invoke Methods

如果工作必须以顺序方式完成，那么就不要使用Parallel方法；同样，避免工作项修改任何类型的共享数据，因为如果多个线程同时维护该数据可能会出现问题；

Parallel.For(), .ForEach(), .Invoke()方法可以接受ParallelObject对象参数；

Parallel.For(), .ForEach()的重载方法可以传入3个委托：

任务本地初始化委托(localInit)，在任务请求处理一个工作项前调用；

主体部分委托(body)，一旦有项目被参与工作的线程处理时被调用；

任务本地终止委托(localFinally)，任务处理完所有的工作项后调用，即使遇到异常。

Parallel Language Integrated Query

使用LINQ，可以简便的进行过滤、排序、投影等操作。但是这些处理过程是顺序的；

Parallel LINQ，以并行的方式使用LINQ。System.LINQ.ParallelQuery；

要使用Parallel LINQ，必须使用ParallelEnumerable.AsParallel()扩展方法从顺序查询(基于IEnumerable或IEnumerable)转换成并行查询(基于ParallelQuery或ParallelQuery)；

如果需要让Parallel LINQ保持处理的顺序，需要调用ParallelEnumerable.AsOrdered()扩展方法；

以无序方式处理的行为：Distinct, Except, Intersect, Union, Join, GroupBy, GroupJion, ToLookup；

以有序方式处理的行为：OrderBy, OrderbyDescending, ThenBy, ThenByDescending；

WithDegreeOfParallelism()方法指定同时处理的最多的线程数量。缺省情况下，线程数量等于CPU核的数量；

Parallel LINQ会分析查询然后决定如何处理最佳；

有时候顺序处理会获得最佳性能，比如：Concat, ElementAt(OrDefault), First(OrDefault), Last(OrDefault), Skip(While), Take(While), Zip。以及在选择器(selector)和断言(predicate)委托中含有位置指示的Select(Many)和Where；

如果你希望强制并行方式处理，可以调用WithExecutionMode()，传入ParallelExecutionMode {Default, ForceParallelism}标志；

WithMergeOptions()，可以用来控制查询结果集合并缓存，也就是时空权衡，传入ParallelMergeOptions {Default, NoBuffered, AutoBuffered, FullyBuffered}标志；

Performing a Periodic Compute-Bound Operation

System.Threading.Timer，构造时可以有TimerCallback回调参数；

当一个Timer对象被当作垃圾收集后，它的终止化方法告诉线程池取消该定时器因此不再离开。因此当使用Timer对象时，确定有变量保持Timer对象存活否则你的回调方法将停止调用；

有很多的定时器，之间有什么差异呢？

System.Threading.Timer，最好的定时器，如果要执行间隙性的后台任务，首选它；

System.Windows.Forms.Timer，类似于Win32的SetTimer函数，当定时器消失时，Windows会插入一个WM_TIMER在线程的消息队列中。不能被多线程同时执行。回调方法的线程必须和设置定时器的线程是同一线程；

System.Threading.DispatcherTimer，用于WPF和SilverLight，等同于System.Windows.Forms.Timer；

System.Timer.Timer，唯一的好处就是可以用于在设界面计器上拖拽，除非真的有必要，否则就不要用。

How the Thread Pool Manages Its Threads

线程池的默认最多线程数量是1000，这在32位系统2G的内存地址空间下是比较合理的限制。CLR项目组会进行合理调整，不要自行修改；

System.Threading.ThreadPool.GetMaxThreads(), .SetMaxThreads(), .GetMinThreads(), .SetMinThreads(), .GetAvailableThreads()；

CLR的线程池有一个全局队列，每个工作线程有一个本地队列；

全局队列采用FIFO算法；本地队列采用LIFO算法。

Cache Lines and False Sharing

CPU逻辑上将内存划分为缓存行(cache line)，在64位的机器系统上，一个缓存行包含64字节，因此CPU以64字节块对RAM进行存取；

因此，如果是64位的机器系统，需要读取Int32的变量，那么包含该变量(4Bytes)的64Bytes的内存块会被读取。读取更多的字节可能会有很好的性能提升，因为大多数应用程序趋向于访问临近的数据，这样数据就很可能已经在Cache中，不需要再从RAM中读取；

但是，如果如果两核或多核访问的数据在同一个缓存行上，这些CPU核就需要进行协调，反而会极大的对性能造成负面影响；

Win32的GetProcessorInformation()函数可以获得CPU的缓存行大小；

[StructLayout(LayoutKind.Explicit)]和[FieldOffest(...)]以缓存行大小递增可以控制字段的布局，以避免需要多线程访问的临近数据不在同一个缓存行上；

因为内存布局和缓存行的缘故。从程序的观点，两个线程管理不同的数据。但是从CPU的观点，两个CPU核却是管理相同的数据。这叫做：虚假共享(False Sharing)；

如果这些CPU在不同的NUMA节点上，虚假共享(False Sharing)会对性能造成极其负面的影响；

要避免虚假共享(False Sharing)，应该避免一个线程写数组的前几个元素而其他的线程在访问数组的其他元素。

本章小结

本章讲了计算方向的异步操作问题，首先隆重推出了CLR的线程池概念，给线程池的线程划分了两个类别：工作者线程和I/O线程。然后演示了如何简单的使用线程池实现一个多线程计算操作；接着讨论了线程池的线程执行体上下文结构；然后引出了协作式取消模式以解释如何在线程池中取消操作；本章重点讨论了Task，一种使用线程池的更强大易用方法，并演示了如何等待任务完成获得结果，如何取消任务，如何在一个任务完成后自动的开始另外一个任务，如何由一个任务开始子任务。接着分析了Task的实现机制和调度策略，如何利用TaskFactory工厂模式创建任务。本章还讲述了如何使用Parallel LINQ以及它的限制和注意事项；接着还讨论了定时器的作用，比较了FCL提供的几种定时器的差异。之后简单解释了线程池是如何管理线程的。最后讨论了高速缓存行和多处理器环境下需要注意的错误共享(False Sharing)问题。

本文链接

CLR Via C# 3rd 阅读摘要 -- Chapter 25 – Thread Basics

2010-06-02T07:34:00Z

Why Does Windows Support Threads?

Windows支持线程可以给系统提供更好的健壮性和交互响应；

Windows一个进程至少有一个主线程，可以启动多个线程，调度单位是线程。

Thread Overhead

跟所有的虚拟化机制一样，线程有时间(运行时执行性能)和空间(内存)的额外开销；

每个线程会包括下列的个别内容：

线程核心对象：一个数据结构，包括一组描述线程的属性。以及调用的线程的上下文信息(一块内存用来放置CPU的寄存器状态)，x86 CPU (≈700Bytes)，x64 CPU(≈1240Bytes)，IA64 CPU(≈2500Bytes)；

线程环境块(TEB)：在用户态(应用代码可以快速访问的地址空间)分配和初始化的内存块。TEB消耗一个内存页面，x86/x64 CPUs(4KB)，IA64 CPU(8KB)。包括异常处理链的头，线程进入每一个try块时会在异常处理链的头部插入一个节点。另外TEB还包括线程的线程本地存储数据；

用户态堆栈：用来存储传到方法的本地变量和参数。Windows默认分配1MB；

核心态堆栈：当操作系统中应用程序代码传递给核心态函数的参数值。32位系统(12KB)，64位系统(24KB)；

DLL线程进入离开通知：Windows有一个策略，任何时候进程中创建了线程，所有进程中装载的DLL都会调用DllMain方法，附带DLL_THREAD_ATTACH标志。同样的，在线程结束时，DllMain再次被调用，附带DLL_THREAD_DETACH标志。

DisableThreadLibraryCalls，非托管代码调用该Win32函数可以忽略DLL_THREAD_ATTACH和DLL_THREAD_DETACH通知。C#和其他托管代码开发的DLL没有DllMain所以没有此缺陷；

上下文切换：分配给线程的CPU时间片配额用完后，Windows会切换到其他线程执行。会执行以下动作：

1.保存CPU寄存器的值到当前运行的线程的核心对象数据结构中；

2.从现存的线程集中调度一个线程。如果该线程属于其他进程，Windows还必须切换虚拟地址空间；

3.从目前调度的线程核心对象数据结构中装载值到寄存器。

当CPU时间片用完后，Windows可能会调度同一个线程，这种情况下不会执行上下文切换；

线程可以自愿的提前结束时间片，经常发生在I/O操作(键盘、网络、鼠标、……)完成时；

当执行垃圾收集时，CLR必须挂起所有的线程完成一系列检查清理操作。因此避免多线程可以极大的改进垃圾收集器的效率；

当使用Debugger时，Windows也会挂起所有的线程；

多CPU的计算机可以同时运行多个线程，增加了扩展性；

Windows保证不会同时将一个线程调度到不同的CPU核上，因为这将引起灾难。

Stop the Madness

虽然创建线程的开销比进程小的多，但是跟系统资源比较起来还是很昂贵的，所以应该避免滥用。

CPU Trends

三种主流多CPU技术：一台计算机多片CPU、超线程CPU、多核CPU。

NUMA Architecture Machines

ccNUMA: Cache-Coherent Non-Uniform Memory Access(连续缓存的非均匀存储器存取)。设计用于多处理器的计算机内存，访问内存时依赖于处理器相关的内存定位。在NUMA情况下，处理器访问自有的本地内存要比非本地(其他处理器共享的)内存快很多；

NUMA的体系结构：

北桥芯片主要决定主板的规格、对硬件的支持、以及系统的性能，它连接着 CPU 、内存、 AGP 总线。主板支持什么 CPU ，支持 AGP 多少速的显卡，支持何种频率的内存，都是北桥芯片决定的。北桥芯片往往有较高的工作频率，所以发热量颇高，我们在主板上，可以在 CPU 插槽附近找到一个散热器，下面的就是北桥芯片。同北桥芯片的主板，性能差别微乎其微；

南桥芯片主要决定主板的功能，主板上的各种接口（如串口、 USB ）、 PCI 总线（接驳电视卡、内猫、声卡等）、 IDE （接硬盘、光驱）、以及主板上的其他芯片（如集成声卡、集成 RAID 卡、集成网卡等），都归南桥芯片控制。南桥芯片通常裸露在 PCI 插槽旁边，块头比较大；

一台计算机可以有一个或多个处理器组，每个处理器组有一个或多个NUMA节点，每个NUMA节点包含多个逻辑处理器、高速缓存、本地内存，每个NUMA节点有一个或多个插槽芯片，每个插槽芯片有一个或多个CPU核，每个CPU核包含一个或多个逻辑处理器。Windows 2008支持256个逻辑处理器；

目前CLR还没有利用处理器组的优点，所有的线程都创建在0组(默认)，并且在64位Windows上最多只支持64核。

CLR Threads and Windows Threads

目前CLR线程直接应射到Windows线程，但是以后未必会这样，CLR有可能引入自己的逻辑线程概念；

如果需要P/Invoke来最多限度的使用本地代码，使用当前的物理操作系统线程是非常重要的，这需要调用System.Threading.Thread.BeginThreadAffinity()静态方法。当不再需要使用物理线程时，调用Thread.EndThreadAffinity()通知CLR。

Using a Dedicated Thread to Perform an Asynchronous Compute-Bound Operation

本节的内容不建议使用，而推荐优先使用CLR的线程池；

如果要创建自己的线程而不采用线程池，先检查以下条件是否存在：

线程需要运行在非常规权限下。所有的线程池线程运行在正常权限下；

需要线程以前台线程方式运行，避免线程完成任务之前应用程序就over了。所有的线程池线程都是后台模式的；

计算密集任务需要很长时间运行；

有可能需要提前Abort的线程。

如果创建带参数的线程，使用System.Threading.Thread(ParameterizedThreadStart start);构造函数，不推荐使用；

Reasons to Use Threads

使用线程的理由：

隔离代码；

简化代码；

并发执行。

多线程可以充分利用CPU，但是如果想压榨计算机的CPU资源，有两个警告：

1.如果用电池供电的话，100%的cpu利用会很耗电；

2.一些数据中心宁愿10台计算机运行在50%的CPU负载，也不愿意5台计算机运行在100%的CPU负载。因为过热需要HVAC降温因此支付更多的电费。

Threading Scheduling and Priorities

Windows为什么叫抢占式多线程操作系统，因为任何时候一个线程停止后，另外一个线程可以马上被调度；

线程的优先级别从0到31级，其中0, 17~30普通开发者不能使用；

进程优先级(Idle -> Below Normal -> Normal -> Above Normal -> High -> Realtime)与线程优先级(Idle -> Lowest -> Below Normal -> Normal ->Above Normal -> Highest -> Time-Critical)的关联矩阵：

CLR中，ThreadPriority枚举只包括{Lowest, Below Normal, Normal, Above Normal, Highest}五种；

垃圾回收器线程以Time-Critical级别运行；

System.Diagnotics下面有两个类：Process和ProcessThread，分别提供进程和线程的情况。

Foreground Threads versus Background Threads

如果进程中的所有前台线程停止运行，CLR强制结束仍然在运行的后台线程。这些后台线程立即结束，没有异常抛出；

如果希望线程执行的任务真正完成(比如刷新缓冲数据到物理磁盘)，那么可以使用前台线程；

如果是无关紧要的任务(比如重新计算工作表)，那么可以使用后台线程；

创建线程时，默认情况下是前台线程，如何转换成后台线程：Thread t = new Thread(...); t.IsBackground = true;

一般来说，应该尽可能的避免使用前台线程，因为这可能会阻止进程正常终止。

What Now?

CLR的线程池是应该优先使用的；

Wintellect Power Threading Library：可以简化线程同步和异步编程。

本章小结

本章讲述了线程的基本知识。首先介绍了Windows的线程概念，CPU的发展趋势，CLR线程与Windows线程直接的关系。然后分析了使用线程的开销，总结了在什么情况下使用线程，使用线程时要注意哪些问题。接着讲解了NUMA的体系结构。讲述了在什么情形下需用使用确定的线程来完成异步计算密集型任务。接着给出了使用线程的理由。重点深入解释了Windows线程的调度机制，线程的优先级以及和线程优先级之间的关联。本章的结尾讲述了选择前台线程和后台线程的条件。最后还推荐了Wintellect Power Threading Library来简化异步编程和线程同步。

本文链接

CLR Via C# 3rd 阅读摘要 -- Chapter 24 – Runtime Serialization

2010-05-31T07:14:00Z

Serialization/Deserialization Quick Start

序列化是将一个对象以及相关的对象转换成字节流的过程；反序列化就是序列化的逆过程；

System.Runtime.Serialization命名空间；

当序列化一个对象时，Formatter首先抓取程序集标识，并确定程序集通过调用System.Reflection.Assembly.Load()被装载到执行的AppDomain中；

程序集被装载后，Formatter在程序集中查找待反序列化对象所匹配的类型，然后实例化再根据流来初始化实例的字段；

一些扩展程序使用Assembly.LoadFrom()来加载程序集，然后从定义在程序集中的类型来构造对象。这些对象在序列化时没有问题，但是反序列化时，Formatter会尝试使用Assembly.Load()来加载程序集，大多数情况下，CLR不能准确定位程序集文件，所以可能会引发SerializationException；

因为上面的原因，如果使用Assembly.LoadFrom()来加载程序集，那么强烈建议在反序列化之前处理System.AppDomain.AssemblyResolver事件。

Making a Type Serializable

对象在默认情况下是不能序列化的，可以通过给类型加上[Serializable]标签来实现；

[Serializable]属性不能被子类型所继承；

System.Object有[Serializable]属性；

一般来说，推荐大多数类型为可序列化的？(我的看法是那些可能会被跨边界访问的类型)。

Controlling Serialization and Deserialization

至少有两个原因使得你不打算让类型实例的一些字段被序列化：

字段的值在反序列化时已经失效了，比如Windows Kernel对象的句柄(文件、进程、线程、互斥体、事件、信号量、……)；

字段的值可以在反序列化时很简单的重新计算出来。

字段加上[NonSerialized]属性标签可以阻止该字段被序列化；

如果希望字段在反序列化时被重新计算，可以定义一个方法[OnDeserialized]private void OnDeserialized(StreamingContext context){...}；

跟[OnDeserialized]相似的几个属性[OnSerializing] -> [OnSerialized] -> [OnDeserializing] -> [OnDeserialized]；

如果你序列化一个类型的实例，在类型中加入新的字段，然后在尝试反序列化时，Formatter会抛出SerializationException指出成员数目不对，可以通过使用[OptionalField]属性标签来解决该问题。

How Formatters Serialize Type Instances

FormatterServices.GetSerializableMembers(), .GetObjectData(), GetTypeFromAssembly(), GetUninitializedObject(), .PopulateObjectMembers()静态方法。

Controlling the Serialized/Deserialized Data

如何完全的控制序列化/反序列化，可以实现System.Runtime.Serialization.ISerializable接口；

一旦类型继承了ISerializable接口，那么子类型也就必须实现该接口；

建议在GetObjectData方法和特殊构造器上附加[SecurityPermissionAttribute(SecurityAction.Demand, SerializationFormatter = true)]属性标签；

当Formatter在序列化对象图时，先查找每一个对象，如果有一个类型实现了ISerializable接口，Formatter就忽略其他所有的客户属性，并构造一个新的System.Runtime.Serialization.SerializationInfo对象；

总是调用SerializationInfo.AddValue来加入序列化信息到类型中，如果字段的类型实现了ISerializable接口，别在字段上调用GetObjectData，而是调用AddValue；

如果类型是sealed，那么强烈建议将特殊构造声明为private；

如果基类没有实现ISerializable接口，怎样为类型实现该接口？FormatterServices.GetSerializableMembers()。

Streaming Contexts

StreamingContext.State, .Context；

StreamingContextStates {CrossProcess, CrossMachines, File, Persistence, Remoting, Other, Clone, CrossAppDomain, All};

Serializing a Type as a Different Type and Deserializing an Object as a Different Object

Serialization Surrogates

System.Runtime.Serialization.ISerializationSurrogate.GetObjectData(), .SetObjectData()；

BinaryFormatter有一个bug阻止从序列化对象到其他的引用。要解决该问题，需要传一个ISerializationSurrogate对象的引用到FormatterServices.GetSurrogateForCyclicalReference()方法；

SurrogateSelector.AddSurrogate()，多个SurrogateSelector对象可以被链接起来，SurrogateSelector实现了ISurrogateSelector接口。

Overriding the Assembly and/or Type When Deserializing an Object

System.Runtime.Serialization.SerializationBinder使得反序列化对象到不同的类型非常容易。要做到这点，需要定义的类型继承自抽象类SerializationBinder。

本章小结

本章讲了序列化和反序列化的知识，序列化可以讲对象转换成流进行传输或者持久化，在需要的时候通过反序列化在将对象构造出来。首先讲了如何让类型具备序列化的能力，以及如何控制序列化的过程。然后讲了Formatter如何序列化类型实例，如何控制序列化/反序列化的数据，介绍了StreamingContext对象，演示了如何将对象反序列化到不同的类型实例。接着介绍了序列化代理，最后讲了SerializationBinder抽象类可以用来反序列化对象到不同的类型。
本文链接

CLR Via C# 3rd 阅读摘要 -- Chapter 23 – Assembly Loading and Reflection

2010-05-24T06:45:00Z

Assembly Loading

在运行时，JIT编译器使用程序集的TypeDef和AssemblyDef元数据表来确定被引用的类型在哪个程序集中；
CLR内部尝试使用System.Reflection.Assembly.Load静态方法来装载程序集；
使用强名称程序集装载时，Load方法会引起CLR应用版本绑定重定向策略(GAC，应用程序根目录，私有路径子目录，代码基位置)。如果是弱名称程序集，Load方法不会应用版本绑定重定向策略，CLR也不会在GAC中查找程序集；
Load方法string参数的形式："SomeAssembly, Version=2.0.0.0, Culture=neutral, PublicKeyToken=01234567890abcde, ProcessorArchitecutre=MSIL"；
CLR目前支持的ProcessorArchitecture：MSIL，x86，IA64，AMD64；
System.AppDomain.Load(...) (.net 2.0没有的)不同于System.Reflection.Assembly.Load(...)，AppDomain.Load是一个实例方法，用来装载一个特定的程序集到指定的AppDomain，该方法是设计用来给非托管代码调用的，它允许一个宿主注入一个程序集到特定的AppDomain中。托管应用中应该避免使用AppDomain.Load方法；
相关的工具：ILDasm.exe, PEVerify.exe, CorFlags.exe, GACUtil.exe, SGen.exe, SN.exe, XSD.exe；
如果要指定路径装载程序集，可以使用Assembly.LoadFrom(...)方法，LoadFrom会首先调用System.Assembly.AssemblyName.GetAssemblyName(...)，然后调用Load方法；
LoadFrom(...)可以传入URL作为参数，但是建议使用另一个方法UnsafeLoadFrom(...)；
Assembly.LoadFile(...)可以多次装载同一个程序集到单独的AppDomain中，但是CLR不会自动解决程序集依赖问题，必须注册AppDomain.AssemblyResolve事件然后在事件回调方法中显示的装载相关的程序集；
程序集不可以被单独卸载，AppDomain才可以；

将引用的程序集dll作为项目的"嵌入的资源"再编译，可以包装成单独的exe分发，在运行时CLR找不到依赖的dll，这可以通过注册AppDomain.ResolveAssembly事件来解决：

AppDomain.CurrentDomain.AssemblyResolve += (sender, args) => {
     String resourceName = "AssemblyLoadingAndReflection." + new AssemblyName(args.Name).Name + ".dll";
     using (var stream = Assembly.GetExecutingAssembly().GetManifestResourceStream(resourceName)) {
     Byte[] assemblyData = new Byte[stream.Length];
     stream.Read(assemblyData, 0, assemblyData.Length);
     return Assembly.Load(assemblyData);
     }
     };

Using Reflection to Build a Dynamically Extensible Application

System.Reflection命名空间，可以用来构建动态扩展的应用程序；

反射还可以用来在运行时从一个特定的程序集装载特定的类型来完成相关的任务。概念上跟Win32的的LoadLibrary和GetProcAddress方法相似；

早期绑定(编译时)和后期绑定(运行时)。

Reflection Performance

反射的两个主要缺点：

反射没有提供运行时的类型安全；

反射的速度很慢。通过反射来调用成员会损坏性能。

一般情况下应该避免使用反射，如果应用程序需要动态的发现和构造类型实例，可以选择下面两种捷径之一：

使得类型继承自编译时确定的基类型；

(推荐)使得类型实现在编译时确定的接口。

使用上面两种方法时，应该把基类型或接口定义在独立的程序集中，这可以减轻版本问题；

发现定义在程序集中的类型：Assembly.GetExportedType(...)；

FLC中，Sytem.ReflectionOnlyType 继承自 Sytem.RuntimeType 继承自 Sytem.Type 继承自 System.Reflection.MemberInfo；

TypeDelegator用来通过动态的封装Type来子类化一个Type；

System.RuntimeType是FLC内部使用的，一个类型第一次在AppDomain中访问时，CLR构造一个RuntimeType的实例并初始化对象的字段到反射类型的信息；

System.Object.GetType()实际上会返回一个RuntimeType；

typeof操作符，通常用来比较早期绑定和晚期绑定的类型信息；

如何构造一个类型的实例？

System.Activator.CreateInstance(), CreateInstanceFrom();

System.AppDomain.CreateInstance(), CreateInstanceAndUpwarp(), CreateInstanceFrom(), CreateInstanceFromAndUnwarp();

System.Type.InvokeMember();

System.Reflection.ConstructorInfo.Invoke();

System.Activator.CreateInstance()允许构造一个值类型而不必调用构造方法；

数组的动态构造：调用Array.CreateInstance(...)静态方法；

委托的动态构造：调用Delegate.CreateInstance(...)静态方法；

泛型类型的动态构造：调用Type.MakeGenericType(...)实例方法。

Designing an Application That Supports Add-Ins

当构建一个可扩展的应用程序时，应该以接口为中心点。当然也可以用基类代替接口，但通常接口优先，让插件开发者选择自己选择基类；

如何设计一个可扩展的应用程序？步骤：

创建一个宿主SDK程序集，定义方法接口，满足宿主应用和插件之间的通信机制。尽量使用MSCorLib.dll中定义的类型和接口，一旦确定别随意更改；

插件开发者，定义自己的类型在插件程序集中；

创建一个分离的宿主应用程序集包含你应用程序的类型，想干什么就干什么，但是别涉及插件宿主SDK。

Using Reflection to Discover a Type's Member

发现类型的成员，关于类型成员封装信息的反射类型的层次结构:

System.Type继承自System.Reflection.MemberInfo，GetMembers()方法返回继承自MemberInfo(EventInfo, FieldInfo, MethodBase(ConstrcutorInfo, MethodInfo), PropertyInfo, Type)对象的数组；

DeclaringType与ReflectedType属性的区别(比如，public class MyType: Object {public string ToString(){return null;}}，typeof(MyType).GetMembers())：

DeclaringType:获得定义该成员的类(ToString，返回MyType，Equals，返回Object)；

ReflectedType:获得用来获得该成员的类对象(ToString, Equals，都返回MyType)。

反射的对象模型：

如何筛选成员类型：System.Reflection.BindingFlags;Type.GetMembers(), GetNestedTypes(), GetFields(), GetConstructors(), GetMethods(), GetProperties(), GetEvents()；

发现类型的接口：Type.FindInterfaces(), GetInterface(), GetInterfaces()；

调用类型的成员，Type.InvokeMember()；

反射使用CAS(代码访问安全)来确定不被滥用；

一次绑定，多次调用，提高效率；

使用绑定句柄(RuntimeTypeHandle, RuntimeFieldHandle, RuntimeMethodHandle)来减少进程的内存开销。

本章小结

本章讨论了如何构建可动态扩展的应用程序，以及如何通过反射来获得类型信息，创建类型的实例，动态的访问它们的成员。首先介绍了如何加载程序集以及如何通过反射来扩展应用，然后分析了反射会引起的性能问题以及如何减轻影响，然后介绍了构建插件应用程序的途径，最后讲了如何通过反射来调用类型的成员。

本文链接

博客园_bengxia-未来与荣耀

MY 2012 GOALS

Silverlight + WCF + Sharepoint（Silverlight Web Part） 问题集合

CLR Via C# 3rd 阅读摘要 -- Chapter 29 – Hybrid Thread Synchronization Constructs

CLR Via C# 3rd 阅读摘要 -- Chapter 28 – Primitive Thread Synchronization Constructs

本章小结 本章讲述了原生的线程同步结构，首先介绍了类库和线程安全性概念，然后对线程同步模式进行了分类：用户模式与核心模式，接着详细说明了这两种同步模式的实现细节，并举例进行了对比。本文链接

FIX: Unable to find a version of the runtime to run this application.

CLR Via C# 3rd 阅读摘要 -- Chapter 27 – I/O-Bound Asynchronous Operations

The APM and Compute-Bound Operations I/O请求会压入到Windows设备驱动的队列中。然而，委托的BeingInvoke方法通过内部调用TheadPool.QueueUserWorkItem()将计算方向的操作压入到CLR的线程池队列。

CLR Via C# 3rd 阅读摘要 -- Chapter 26 – Compute-Bound Asynchronous Operations

Performing a Simple Compute-Bound Operation TheadPool.QueueUserWorkerItem(WaitCallback callback), .QueueUserWorkerItem(WaitCallback callback, Object state)； 如果回调方法抛出一个异常没有被处理，CLR终止该进程(除非宿主强制使用自己的策略)。

CLR Via C# 3rd 阅读摘要 -- Chapter 25 – Thread Basics

Why Does Windows Support Threads? Windows支持线程可以给系统提供更好的健壮性和交互响应； Windows一个进程至少有一个主线程，可以启动多个线程，调度单位是线程。

Stop the Madness 虽然创建线程的开销比进程小的多，但是跟系统资源比较起来还是很昂贵的，所以应该避免滥用。

CPU Trends 三种主流多CPU技术：一台计算机多片CPU、超线程CPU、多核CPU。

What Now? CLR的线程池是应该优先使用的； Wintellect Power Threading Library：可以简化线程同步和异步编程。

CLR Via C# 3rd 阅读摘要 -- Chapter 24 – Runtime Serialization

How Formatters Serialize Type Instances FormatterServices.GetSerializableMembers(), .GetObjectData(), GetTypeFromAssembly(), GetUninitializedObject(), .PopulateObjectMembers()静态方法。

Streaming Contexts StreamingContext.State, .Context； StreamingContextStates {CrossProcess, CrossMachines, File, Persistence, Remoting, Other, Clone, CrossAppDomain, All};

Serializing a Type as a Different Type and Deserializing an Object as a Different Object

Overriding the Assembly and/or Type When Deserializing an Object System.Runtime.Serialization.SerializationBinder使得反序列化对象到不同的类型非常容易。要做到这点，需要定义的类型继承自抽象类SerializationBinder。

CLR Via C# 3rd 阅读摘要 -- Chapter 23 – Assembly Loading and Reflection

Silverlight + WCF + Sharepoint（Silverlight Web Part）问题集合

本章小结

本章讲述了原生的线程同步结构，首先介绍了类库和线程安全性概念，然后对线程同步模式进行了分类：用户模式与核心模式，接着详细说明了这两种同步模式的实现细节，并举例进行了对比。
本文链接

The APM and Compute-Bound Operations

I/O请求会压入到Windows设备驱动的队列中。然而，委托的BeingInvoke方法通过内部调用TheadPool.QueueUserWorkItem()将计算方向的操作压入到CLR的线程池队列。

Performing a Simple Compute-Bound Operation

TheadPool.QueueUserWorkerItem(WaitCallback callback), .QueueUserWorkerItem(WaitCallback callback, Object state)；

如果回调方法抛出一个异常没有被处理，CLR终止该进程(除非宿主强制使用自己的策略)。

Why Does Windows Support Threads?

Windows支持线程可以给系统提供更好的健壮性和交互响应；

Windows一个进程至少有一个主线程，可以启动多个线程，调度单位是线程。

Stop the Madness

虽然创建线程的开销比进程小的多，但是跟系统资源比较起来还是很昂贵的，所以应该避免滥用。

CPU Trends

三种主流多CPU技术：一台计算机多片CPU、超线程CPU、多核CPU。

What Now?

CLR的线程池是应该优先使用的；

Wintellect Power Threading Library：可以简化线程同步和异步编程。

How Formatters Serialize Type Instances

FormatterServices.GetSerializableMembers(), .GetObjectData(), GetTypeFromAssembly(), GetUninitializedObject(), .PopulateObjectMembers()静态方法。

Streaming Contexts

StreamingContext.State, .Context；

StreamingContextStates {CrossProcess, CrossMachines, File, Persistence, Remoting, Other, Clone, CrossAppDomain, All};

Overriding the Assembly and/or Type When Deserializing an Object

System.Runtime.Serialization.SerializationBinder使得反序列化对象到不同的类型非常容易。要做到这点，需要定义的类型继承自抽象类SerializationBinder。