VC++多线程下内存操作的优化

　　许多程序员发现用VC++编写的程序在多处理器的电脑上运行会变得很慢，这种情况多是由于多个线程争用同一个资源引起的。对于用VC++编写的程序，问题出在VC++的内存管理的具体实现上。以下通过对这个问题的解释，提供一个简便的解决方法，使得这种程序在多处理器下避免出现运行瓶颈。这种方法在没有VC++程序的源代码时也能用。

　　问题

    C和C++运行库提供了对于堆内存进行管理的函数：C提供的是malloc()和free()、C++提供的是new和delete。无论是通过malloc()还是new申请内存，这些函数都是在堆内存中寻找一个未用的块，并且块的大小要大于所申请的大小。如果没有足够大的未用的内存块，运行时间库就会向操作系统请求新的页。页是虚拟内存管理器进行操作的单位，在基于Intel的处理器的NT平台下，一般是4,096字节。当你调用free()或delete释放内存时，这些内存块就返还给堆，供以后申请内存时用。

    这些操作看起来不太起眼，但是问题的关键。问题就发生在当多个线程几乎同申请内存时，这通常发生在多处理器的系统上。但即使在一个单处理器的系统上，如果线程在错误的时间被调度，也可能发生这个问题。

　　考虑处于同一进程中的两个线程，线程1在申请1,024字节的内存的同时，运行于另外一个处理器的线程2申请256字节内存。内存管理器发现一个未用的内存块用于线程1，同时同一个函数发现了同一块内存用于线程2。如果两个线程同时更新内部数据结构，记录所申请的内存及其大小，堆内存就会产生冲突。即使申请内存的函数者成功返回，两个线程都确信自己拥有那块内存，这个程序也会产生错误，这只是个时间问题。

　　产生这种情况称为争用，是编写多线程程序的最大问题。解决这个问题的关键是要用一个锁定机制来保护内存管理器的这些函数，锁定机制保证运行相同代码的多个线程互斥地进行，如果一个线程正运行受保护的代码，则其他的线程都必须等待，这种解决方法也称作序列化。

    NT提供了一些锁定机制的实现方法。CreateMutex()创建一个系统范围的锁定对象，但这种方法的效率最低；InitializeCriticalSection()创建的critical section相对效率就要高许多；要得到更好的性能，可以用具有service pack 3的NT 4的spin lock，更详细的信息可以参考VC++帮助中的InitializeCriticalSectionAndSpinCount()函数的说明。有趣的是，虽然帮助文件中说spin lock用于NT的堆管理器(HeapAlloc()系列的函数)，VC++运行库的堆管理函数并没有用spin lock来同步对堆的存取。如果查看VC++运行库的堆管理函数的源程序，会发现是用一个critical section用于全部的内存操作。如果可以在VC++运行库中用HeapAlloc()，而不是其自己的堆管理函数，将会因为使用的是spin lock而不是critical section而得到速度优化。

　　通过使用critical section同步对堆的存取，VC++运行库可以安全地让多个线程申请和释放内存。然而，由于内存的争用，这种方法会引起性能的下降。如果一个线程存取另外一个线程正在使用的堆时，前一个线程就需要等待，并丧失自己的时间片，切换到其他的线程。线程的切换在NT下是相当费时的，因为其占用线程的时间片的一个小的百分比。如果有多个线程同时要存取同一个堆，会引起更多的线程切换，足够引起极大的性能损失。 

　　现象

    如何发现多处理器系统存在这种性能损失？有一个简便的方法，打开“管理工具”中的“性能”监视器，在系统组中添加一个上下文切换/秒计数，然后运行想要测试的多线程程序，并且在进程组中添加该进程的处理器时间计数，这样就可以得到处理器在高负荷下要发生多少次上下文切换。

　　在高负荷下有上千次的上下文切换是正常的，但当计数超过80,000或100,000时，说明过多的时间都浪费在线程的切换，稍微计算一下就可以知道，如果每秒有100,000次线程切换，则每个线程只有10微秒用于运行，而NT上的正常的时间片长度约有12毫秒，是前者的上千倍。

    图1的性能图显示了过度的线程切换，而图2显示了同一个进程在同样的环境下，在使用了下面提供的解决方法后的情况。图1的情况下，系统每秒钟要进行120,000次线程切换，改进后，每秒钟线程切换的次数减少到1,000次以下。两张图都是在运行同一个测试程序时截取得，程序中同时有3个线程同时进行最大为2，048字节的堆的申请，硬件平台是一个双Pentium II 450机器，有256MB内存。