线程同步是多线程程序设计的核心内容，它的目的是正确处理多线程并发时的各种问题，例如线程的等待、多个线程访问同一数据时的互斥，防死锁等。 Win32提供多种内核对象和手段用于线程同步，如互斥量、信号量、事件、临界区等。所不同的是，互斥量、信号量、事件都是Windows的内核对象，当 程序对这些对象进行控制时会自动转换到核心态，而临界区本身不是内核对象，它是工作在用户态的。我们知道从用户态转换到核心态是需要以时间为代价的，所以 如果能在用户态就简单解决的问题，就可以不必劳烦核心态了。
这里我要说的是两种用于C++的多线程同步类，通过对这两种类的使用就可以方便的实现对变量或代码段的加锁控制，从而防止多线程对变量不正确的操作。
所 谓加锁，就是说当我们要访问某关键变量之前，都需要首先获得允许才能继续，如果未获得允许则只有等待。一个关键变量拥有一把锁，一个线程必须先得到这把锁 （其实称为钥匙可能更形象）才可以访问这个变量，而当某个变量持有这把锁的时候，其他线程就不能重复的得到它，只有等持有锁的线程把锁归还以后其他线程才 有可能得到它。之所以这样做，就是为了防止一个线程读取某对象途中另一线程对它进行了修改，或两线程同时对一变量进行修改，例如：
如果实际的执行顺序就是上述书写的顺序那到没有什么，但如果线程2的执行打断了线程1，变为如下顺序：
int a = s.a; //线程1
s.a++; //线程2
s.b++; //线程2
int b = s.b; //线程1
那 么这时线程1读出来的a和b就会有问题了，因为a是在修改前读的，而b是在修改后读的，这样读出来的是不完整的数据，会对程序带来不可预料的后果。天知道 两个程的调度顺序是什么样的。为了防止这种情况的出现，需要对变量s加锁，也就是当线程1得到锁以后就可以放心的访问s，这时如果线程2要修改s，只有等 线程1访问完成以后将锁释放才可以，从而保证了上述两线程交叉访问变量的情况不会出现。
使用Win32提供的临界区可以方便的实现这种锁：
代码中的临界区变量（cs）就可以看作是变量s的锁，当函数EnterCriticalSection返回时，当前线程就获得了这把锁，之后就是对变量的访问了。访问完成后，调用LeaveCriticalSection表示释放这把锁，允许其他线程继续使用它。
如 果每当需要对一个变量进行加锁时都需要做这些操作，显得有些麻烦，而且变量cs与s只有逻辑上的锁关系，在语法上没有什么联系，这对于锁的管理带来了不小 的麻烦。程序员总是最懒的，可以想出各种偷懒的办法来解决问题，例如让被锁的变量与加锁的变量形成物理上的联系，使得锁变量成为被锁变量不可分割的一部 分，这听起来是个好主意。
首先想到的是把锁封闭在一个类里，让类的构造函数和析构函数来管理对锁的初始化和锁毁动作，我们称这个锁为“实例锁”：
};
;
什 么？结构体还能从类继承？当然，C++中结构体和类除了成员的默认访问控制不同外没有什么不一样，class能做的struct也能做。此外，也许你还会 问，如果被锁的是个简单类型，不能继承怎么办，那么要么用一个类对这个简单类型进行封装（记得Java里有int和Integer吗），要么只好手工管理 它们的联系了。如果被锁类已经有了基类呢？没关系，C++是允许多继承的，多一个基类也没什么。
现在我们的数据里面已经包含一把锁了，之后就是要添加加锁和解锁的动作，把它们作为InstanceLockBase类的成员函数再合适不过了：
…
}
看 到这里可能会发现，我把Lock和Unlock函数都声明为私有了，那么如何访问这两个函数呢？是的，我们总是需要有一个地方来调用这两个函数以实现加锁 和解锁的，而且它们总应该成对出现，但C++语法本身没能限制我们必须成对的调用两个函数，如果加完锁忘了解，那后果是严重的。这里有一个例外，就是C+ +对于构造函数和析构函数的调用是自动成对的，对了，那就把对Lock和Unlock的调用专门写在一个类的构造函数和析构函数中：
