线程/进程同步问题

. 计算机网络课程实验要做一个c/s模型的文件传递程序。本来socket编程我还是比较熟悉的，因为以前用VC/MFC编过一个网络游戏——网络五子棋，并通过设置NAT与新加坡的同学对战了一把。这次的程序本来更简单，但是老师要用纯windows API来写，不准用其他的类库，于是工作的重点就转移到了怎样构建一个自己的支持异步调用的Socket类，一涉及到异步调用，肯定又得用到多线程，所以还得构建一个自己的线程类，如果有可能可以再实现一个线程池来提高运行效率。

可以看出所有问题的关键在于实现这个线程类，因为其他的都是简单的对API进行一次封装，而线程类实现的好坏将直接影响到异步调用的方便性和安全性。多线程问题中一个最头痛的问题便是进程同步。而我的线程类就要实现一个方法Thread.Join()来帮助用户同步线程，此方法将阻塞调用线程（即主进程）直到被调进程（子进程）执行完毕，从而达到同步的效果。

翻翻《windows核心编程》，找到了一个event核心对象，可以实现进程同步，模型很简单，一个线程里阻塞wait一个特定的event，直到另外一个线程set这个event，即触发这个事件。但我马上想到了一个问题，如果在主线程等待某个事件之前，子线程已经触发过了这个事件，怎么办？等待将会一直阻塞吗？由于本人一时不小心，犯了一个错误，导致了这个问题的验证过程略趋复杂了一些，在此就略去，仅将答案公布于下：不会一直锁住，如果事件已经触发了，event提供了2种复位的方法，一种是manul（人工），即显示调用函数ResetEvent，另一种是auto（自动），即第一个wait此event的线程（或进程）得到响应之后便自动复位。所以，当事件先触发而等待此事件的代码滞后时也不会导致wait无穷阻塞，因为event自己维护了一个自己的状态。

这不和Semphore（信号量）一模一样了吗？所以这个地方，如果熟悉信息量操作的话，就不必用这个event了。后来进一步发现，什么mutex，event，criticalregion都是可以靠semphore来实现的，或者说是semphore使用的一些特例。所以，要学好线程（或进程）同步问题，学好Semphore，即P，V操作才是王道！