不知道大家对多线程或多进程间的同步相互排斥的控制机制了解的怎么样，事实上有非常多种方法能够实现这个目的，可是这些方法事实上由4种最主要的方法实现。这4种最主要的方法详细定义例如以下：在这有讲得不正确的地方欢迎各位扔砖，希望不会误导大家。
1、临界区:通过对多线程的串行化来訪问公共资源或一段代码，速度快，适合控制数据訪问。
2、相互排斥量:为协调共同对一个共享资源的单独訪问而设计的。
3、信号量:为控制一个具有有限数量用户资源而设计。
4、事 件:用来通知线程有一些事件已发生，从而启动后继任务的開始。
临界区（Critical?Section）(以win32系统为例)
保证在某一时刻仅仅有一个线程能訪问数据的简便办法。在随意时刻仅仅同意一个线程对共享资源进行訪问。假设有多个线程试图同一时候訪问临界区，那么在有一个线程进入后其它全部试图訪问此临界区的线程将被挂起，并一直持续到进入临界区的线程离开。临界区在被释放后，其它线程能够继续抢占，并以此达到用原子方式操作共享资源的目的。临界区包括两个操作原语：
EnterCriticalSection（）进入临界区
LeaveCriticalSection（）离开临界区
EnterCriticalSection（）语句运行后代码将进入临界区以后不管发生什么，必须确保与之匹配的LeaveCriticalSection（）都可以被运行到。否则临界区保护的共享资源将永远不会被释放。尽管临界区同步速度非常快，但却仅仅能用来同步本进程内的线程，而不可用来同步多个进程中的线程。
相互排斥量（Mutex）
相互排斥量跟临界区非常相似，仅仅有拥有相互排斥对象的线程才具有訪问资源的权限，由于相互排斥对象仅仅有一个，因此就决定了不论什么情况下此共享资源都不会同一时候被多个线程所訪问。当前占领资源的线程在任务处理完后应将拥有的相互排斥对象交出，以便其它线程在获得后得以訪问资源。相互排斥量比临界区复杂。由于使用相互排斥不仅仅可以在同一应用程序不同线程中实现资源的安全共享，并且可以在不同应用程序的线程之间实现对资源的安全共享。
相互排斥量包括的几个操作原语：
CreateMutex（） 创建一个相互排斥量
OpenMutex（） 打开一个相互排斥量
ReleaseMutex（） 释放相互排斥量
WaitForMultipleObjects（） 等待相互排斥量对象
信号量（Semaphores）
信号量对象对线程的同步方式与前面几种方法不同，信号同意多个线程同一时候使用共享资源，这与操作系统中的PV操作同样。它指出了同一时候訪问共享资源的线程最大数目。它同意多个线程在同一时刻訪问同一资源，可是须要限制在同一时刻訪问此资源的最大线程数目。在用CreateSemaphore（）创建信号量时即要同一时候指出同意的最大资源计数和当前可用资源计数。通常是将当前可用资源计数设置为最大资源计数，每添加一个线程对共享资源的訪问，当前可用资源计数就会减1，仅仅要当前可用资源计数是大于0的，就能够发出信号量信号。可是当前可用计数减小到0时则说明当前占用资源的线程数已经达到了所同意的最大数目，不能在同意其它线程的进入，此时的信号量信号将无法发出。线程在处理完共享资源后，应在离开的同一时候通过ReleaseSemaphore（）函数将当前可用资源计数加1。在不论什么时候当前可用资源计数决不可能大于最大资源计数。 PV操作及信号量的概念都是由荷兰科学家E.W.Dijkstra提出的。信号量S是一个整数，S大于等于零时代表可供并发进程使用的资源实体数，但S小于零时则表示正在等待使用共享资源的进程数。P操作申请资源：
（1）S减1；
（2）若S减1后仍大于等于零，则进程继续运行；
（3）若S减1后小于零，则该进程被堵塞后进入与该信号相相应的队列中，然后转入进程调度。
V操作 释放资源：
（1）S加1；
（2）若相加结果大于零，则进程继续运行；
（3）若相加结果小于等于零，则从该信号的等待队列中唤醒一个等待进程，然后再返回原进程继续运行或转入进程调度。
信号量包括的几个操作原语：
CreateSemaphore（） 创建一个信号量
OpenSemaphore（） 打开一个信号量
ReleaseSemaphore（） 释放信号量
WaitForSingleObject（） 等待信号量
事件（Event）
事件对象也能够通过通知操作的方式来保持线程的同步。而且能够实现不同进程中的线程同步操作。
信号量包括的几个操作原语：
CreateEvent（）创建一个信号量
OpenEvent（）打开一个事件
SetEvent（）?回置事件
WaitForSingleObject（）等待一个事件
WaitForMultipleObjects（）等待多个事件
应网友要求，在此贴相互排斥--Mutex的简略版希望对你们实用，这个简略版的Mutex能够跨多个平台，比方：win32、linux、android等等类unix的系统。谢谢！
#ifndef HEART_MOBIHEART_MMUTEX_H
#define HEART_MOBIHEART_MMUTEX_H
#ifdef WIN32
# include <windows.h>
#else
# include <pthread.h>
#endif
#ifdef WIN32
typedef CRITICAL_SECTION MOBI_MUTEX_SECTION;
# define MOBI_MUTEX_INIT ::InitializeCriticalSection
# define MOBI_MUTEX_DESTROY ::DeleteCriticalSection
# define MOBI_MUTEX_LOCK ::EnterCriticalSection
# define MOBI_MUTEX_UNLOCK ::LeaveCriticalSection
#else
typedef pthread_mutex_t MOBI_MUTEX_SECTION;
# define MOBI_MUTEX_INIT pthread_mutex_init
# define MOBI_MUTEX_DESTROY pthread_mutex_destroy
# define MOBI_MUTEX_LOCK pthread_mutex_lock
# define MOBI_MUTEX_UNLOCK pthread_mutex_unlock
#endif
class Mutex
{
public:
Mutex()
{
MOBI_MUTEX_INIT(&m_mutex
#ifndef _WIN32
, NULL
#endif
);
}
virtual ~Mutex() {MOBI_MUTEX_DESTROY(&m_mutex);}
virtual void Lock() const {MOBI_MUTEX_LOCK(&m_mutex);}
virtual void Unlock() const { MOBI_MUTEX_UNLOCK(&m_mutex); }
private:
mutable MOBI_MUTEX_SECTION m_mutex;
};
class AutoLock
{
public:
AutoLock(const Mutex& mutex, bool autolocked = true) : m_mutex(&mutex), m_locked(true)
{
if(autolocked)
{
m_mutex->Lock();
m_locked = autolocked;
}
};
~AutoLock()
{
if(m_locked)
{
m_mutex->Unlock();
}
};
private:
const Mutex* m_mutex;
bool m_locked;
};
#ifndef LOCK
# define LOCK(mutex) AutoLock locker(mutex)
#endif
#endif//HEART_MOBIHEART_MMUTEX_H