ACE下的ACE_Condition_Thread_Mutex和WIN32的EVENT比较以及ACE_Event

从《C++ NP V1》这本书上的描述，如果不仔细看很容易将ACE_Condition_Thread_Mutex误以为是WIN32当中的EVENT同样的东东，然后仔细揣摩书中的描述和相关文档，我们会发现这其实是两个毫不相关的东西。

首先，从ACE_Condition_Thread_Mutex这个名字当中我们可以知道，这个同步ACE对象其实是进程范围内的，而根据我们所知，WIN32的EVENT是内核对象，也就是可以做进程同步的系统范围对象。当然这只是初步的区别。

观察ACE_Condition_Thread_Mutex这个类的构造函数，我们发现他必须传递一个ACE_Thread_Mutex对象给他，再仔细看书中的描述，我们可以看到，在调用ACE_Condition_Thread_Mutex::wait()之前，我们必须先将mutex锁定(acquire)。而ACE_Condition_Thread_Mutex在wait过程中（也就是没有其他线程将其signal或者broadcast），实际上传递进去的mutex是被release的（关于这点，完全可以写个测试程序来进行验证，我这有测试程序），当condition对象被signal以后，wait调用返回，但是此时mutex被重新锁定，于是这里出现了一个初次使用经常会犯的错误，就是这里忘了将mutex重新释放，于是导致了死锁。这里推荐使用ACE_GUARD宏来处理这个mutex。

所以说，从上面两点来看，ACE_Condition_Thread_Mutex跟EVENT压根是两码事，特别是第二点，ACE的设计者大概是为了防止在mutex上造成死锁才设计成这样（毕竟mutex是作为一个变量传递进去的，很有可能在其他地方被重新使用）。

那么在ACE当中与WIN32的EVENT等同的东西是什么呢？应该是ACE_Event的两个子类：ACE_Manual_Event和ACE_Auto_Event，但是这两个类有一定的缺陷，我们可以看到文档当中的第一句话就讲了A wrapper around the Win32 event locking mechanism，这是一个for WIN32的wrapper，仔细看下面的文档，我们会发现，在非WIN32的Platform上，EVENT被模拟成进程范围内的东西，这又接近ACE_Condition_Thread_Mutex了（我没看源码，很有可能就是同一个东西），当然在WIN32上ACE_Event还是我们熟悉的那个Event，只能说如果需要移植那就尽量少用吧。

Portable implementation of an Event mechanism, which is native to Win32, but must be emulated on UNIX. All platforms support process-scope locking support. However, only Win32 platforms support global naming and system-scope locking support.