InterlockedIncrement和InterlockedDecrement的妙用

    一般来说，在多用户线程环境中，我们使用临界区、事件对象甚至互斥量来进行同步，尤其是临界区，可以很方便地对某些变量甚至代码块进行锁定执行，防止多线程之间资源恶性抢夺。既然如此，为啥微软又单独提供了专用于一个数值锁定计算的API函数InterlockedIncrement和InterlockedDecrement呢？他们又有什么特殊作用呢？
    恰好近段时间写了一个这方面的应用，帮我加深了对这类API函数的理解。
    首先描述一下需求，在应用中，有这样一个类，它可能只被实例化一次，也可能会被实例化多次，但不管被实例化了几次，它必须在构造函数里执行一项初始化计算，假设初始化计算的函数为WSAStartup，同时还需要在析构函数里执行一下注销计算，假设注销计算的函数为WSACleanup，现在有一个要求，就是它们的初始化和注销计算只能被执行一次，就如同在一个项目中，只能运行一次WSAStartup和WSACleanup一样。当然，大家可能会想到直接在工程的开始和结尾处实现这样的功能，但是，如果把这个类的文件包括在其它测试工程里进行测试，同时不改变其它工程的代码，又该如何实现呢？
    其实，我们可以充分利用InterlockedIncrement和InterlockedDecrement，就如同COM的CoInitialize()和CoUninitialize()一样，描述代码如下：

    假设类名为A：

class A { protected: static long m_nRef; public: //类A的构造函数 A() { if(1 == InterlockedIncrement(&m_nRef)) { //以下代码只执行一次 WSADATA wsaData; WSAStartup(MAKEWORD(2,2), &wsaData); } }; //类A的虚析构函数 virtual ~A() { if(0 == InterlockedDecrement(&m_nRef)) { //以下代码只执行一次 WSACleanup(); } } }; long A::m_nRef = 0;

    这样，无论我们创建了类A的多少个实例，在类的构造函数和析构函数里，WSAStartup和WSACleanup均只被执行一次，有效地保证了单元代码的封装性。