delphi线程类【这个文章可以帮我们了解多线程编程】2

导读：
　　顺便再介绍一下另一个用于线程同步的类：TMultiReadExclusiveWriteSynchronizer，它是在SysUtils单元中定义的。据我所知，这是Delphi RTL中定义的最长的一个类名，还好它有一个短的别名：TMREWSync。至于它的用处，我想光看名字就可以知道了，我也就不多说了。
　　有了前面对Event和CriticalSection的准备知识，可以正式开始讨论Synchronize和WaitFor了。
　　我们知道，Synchronize是通过将部分代码放到主线程中执行来实现线程同步的，因为在一个进程中，只有一个主线程。先来看看Synchronize的实现：
　　procedure TThread.Synchronize(Method: TThreadMethod);
　　begin
　　FSynchronize.FThread := Self;
　　FSynchronize.FSynchronizeException := nil;
　　FSynchronize.FMethod := Method;
　　Synchronize(@FSynchronize);
　　end;
　　其中FSynchronize是一个记录类型：
　　PSynchronizeRecord = ^TSynchronizeRecord;
　　TSynchronizeRecord = record
　　FThread: TObject;
　　FMethod: TThreadMethod;
　　FSynchronizeException: TObject;
　　end;
　　用于进行线程和主线程之间进行数据交换，包括传入线程类对象，同步方法及发生的异常。
　　在Synchronize中调用了它的一个重载版本，而且这个重载版本比较特别，它是一个“类方法”。所谓类方法，是一种特殊的类成员方法，它的调用并不需要创建类实例，而是像构造函数那样，通过类名调用。之所以会用类方法来实现它，是因为为了可以在线程对象没有创建时也能调用它。不过实际中是用它的另一个重载版本（也是类方法）和另一个类方法StaticSynchronize。下面是这个Synchronize的代码：
　　class procedure TThread.Synchronize(ASyncRec: PSynchronizeRecord);
　　var
　　SyncProc: TSyncProc;
　　begin
　　if GetCurrentThreadID = MainThreadID then
　　ASyncRec.FMethod
　　//首先是判断当前线程是否是主线程，如果是，则简单地执行同步方法后返回。
　　else begin
　　SyncProc.Signal := CreateEvent(nil, True, False, nil);
　　{通过局部变量SyncProc记录线程交换数据（参数）和一个Event Handle，其记录结构如下：
　　TSyncProc = record
　　SyncRec: PSynchronizeRecord;
　　Signal: THandle;
　　end; }
　　try
　　EnterCriticalSection(ThreadLock);{接着进入临界区（通过全局变量ThreadLock进行，因为同时只能有一个线程进入Synchronize状态，所以可以用全局变量记录）
　　} try
　　{然后就是把这个记录数据存入SyncList这个列表中（如果这个列表不存在的话，则创建它）。} if SyncList = nil then SyncList := TList.Create;
　　//
　　SyncProc.SyncRec := ASyncRec;
　　SyncList.Add(@SyncProc);
　　{ 再接下就是调用SignalSyncEvent，其代码在前面介绍TThread的构造函数时已经介绍过了，它的功能就是简单地将SyncEvent作一个Set的操作。关于这个SyncEvent的用途，将在后面介绍WaitFor时再详述。}
　　SignalSyncEvent;
　　{接下来就是最主要的部分了：调用WakeMainThread事件进行同步操作。WakeMainThread是一个TNotifyEvent类型的全局事件。这里之所以要用事件进行处理，是因为Synchronize方法本质上是通过消息，将需要同步的过程放到主线程中执行，如果在一些没有消息循环的应用中（如Console或DLL）是无法使用的，所以要使用这个事件进行处理。} if Assigned(WakeMainThread) then WakeMainThread(SyncProc.SyncRec.FThread);
　　LeaveCriticalSection(ThreadLock);
　　//在执行完WakeMainThread事件后，就退出临界区
　　try
　　WaitForSingleObject(SyncProc.Signal, INFINITE);
　　{然后调用WaitForSingleObject开始等待在进入临界区前创建的那个Event。这个Event的功能是等待这个同步方法的执行结束，关于这点，在后面分析CheckSynchronize时会再说明。}
　　finally
　　EnterCriticalSection(ThreadLock);
　　end;
　　{注意在WaitForSingleObject之后又重新进入临界区，但没有做任何事就退出了，似乎没有意义，但这是必须的！
　　因为临界区的Enter和Leave必须严格的一一对应。那么是否可以改成这样呢：
　　if Assigned(WakeMainThread) then
　　WakeMainThread(SyncProc.SyncRec.FThread);
　　WaitForSingleObject(SyncProc.Signal, INFINITE);
　　f inally
　　LeaveCriticalSection(ThreadLock);
　　end;
　　上面的代码和原来的代码最大的区别在于把WaitForSingleObject也纳入临界区的限制中了。看上去没什么影响，还使代码大大简化了，但真的可以吗？事实上是不行！
　　因为我们知道，在Enter临界区后，如果别的线程要再进入，则会被挂起。而WaitFor方法则会挂起当前线程，直到等待别的线程SetEvent后才会被唤醒。如果改成上面那样的代码的话，如果那个SetEvent的线程也需要进入临界区的话，死锁（Deadlock）就发生了（关于死锁的理论，请自行参考操作系统原理方面的资料）。死锁是线程同步中最需要注意的方面之一！
　　} finally
　　LeaveCriticalSection(ThreadLock);
　　end;
　　finally
　　CloseHandle(SyncProc.Signal);
　　end;
　　//最后释放开始时创建的Event，如果被同步的方法返回异常的话，还会在这里再次抛出异常。
　　if Assigned(ASyncRec.FSynchronizeException) then
　　raise ASyncRec.FSynchronizeException;
　　end;
　　end;
　　这段代码略多一些，不过也不算太复杂。
　　可见ThreadLock这个临界区就是为了保护对SyncList的访问，这一点在后面介绍CheckSynchronize时会再次看到。
　　而响应这个事件的是Application对象，下面两个方法分别用于设置和清空WakeMainThread事件的响应（来自Forms单元）：
　　 procedure TApplication.HookSynchronizeWakeup;
　　 begin
　　 Classes.WakeMainThread := WakeMainThread;
　　 end;
　　 procedure TApplication.UnhookSynchronizeWakeup;
　　 begin
　　 Classes.WakeMainThread := nil;
　　 end;
　　上面两个方法分别是在TApplication类的构造函数和析构函数中被调用。
　　这就是在Application对象中WakeMainThread事件响应的代码，消息就是在这里被发出的，它利用了一个空消息来实现：
　　procedure TApplication.WakeMainThread(Sender: TObject);
　　begin
　　PostMessage(Handle, WM_NULL, 0, 0);
　　end;
　　而这个消息的响应也是在Application对象中，见下面的代码（删除无关的部分）：
　　procedure TApplication.WndProc(var Message: TMessage);
　　…
　　begin
　　try
　　…
　　with Message do
　　case Msg of
　　…
　　WM_NULL:
　　CheckSynchronize;
　　…
　　except
　　HandleException(Self);
　　end;
　　end;
　　其中的CheckSynchronize也是定义在Classes单元中的，由于它比较复杂，暂时不详细说明，只要知道它是具体处理Synchronize功能的部分就好.
　　回到前面CheckSynchronize，见下面的代码：
　　function CheckSynchronize(Timeout: Integer = 0): Boolean;
　　var
　　SyncProc: PSyncProc;
　　LocalSyncList: TList;
　　begin
　　//首先，这个方法必须在主线程中被调用（如前面通过消息传递到主线程），否则就抛出异常。
　　if GetCurrentThreadID <>MainThreadID then
　　raise EThread.CreateResFmt(@SCheckSynchronizeError, [GetCurrentThreadID]);
　　{接下来调用ResetSyncEvent（它与前面SetSyncEvent对应的，之所以不考虑WaitForSyncEvent的情况，是因为只有在Linux版下才会调用带参数的CheckSynchronize，Windows版下都是调用默认参数0的CheckSynchronize）。}
　　if Timeout >0 then
　　WaitForSyncEvent(Timeout)
　　else
　　ResetSyncEvent;
　　{现在可以看出SyncList的用途了：它是用于记录所有未被执行的同步方法的。因为主线程只有一个，而子线程可能有很多个，当多个子线程同时调用同步方法时，主线程可能一时无法处理，所以需要一个列表来记录它们。}
　　LocalSyncList := nil;
　　EnterCriticalSection(ThreadLock);
　　try
　　Integer(LocalSyncList) := InterlockedExchange(Integer(SyncList), Integer(LocalSyncList));
　　try
　　Result := (LocalSyncList <>nil) and (LocalSyncList.Count >0);
　　if Result then begin
　　{在这里用一个局部变量LocalSyncList来交换SyncList，这里用的也是一个原语：InterlockedExchange。同样，这里也是用临界区将对SyncList的访问保护起来。只要LocalSyncList不为空，则通过一个循环来依次处理累积的所有同步方法调用。最后把处理完的LocalSyncList释放掉，退出临界区。} while LocalSyncList.Count >0 do begin
　　{再来看对同步方法的处理：首先是从列表中移出（取出并从列表中删除）第一个同步方法调用数据。然后退出临界区（原因当然也是为了防止死锁）。接着就是真正的调用同步方法了。}
　　SyncProc := LocalSyncList[0];
　　LocalSyncList.Delete(0);
　　LeaveCriticalSection(ThreadLock);
　　
　　try
　　try
　　SyncProc.SyncRec.FMethod;
　　except //如果同步方法中出现异常，将被捕获后存入同步方法数据记录中。
　　SyncProc.SyncRec.FSynchronizeException := AcquireExceptionObject;
　　end;
　　finally
　　EnterCriticalSection(ThreadLock);
　　{重新进入临界区后，调用SetEvent通知调用线程，同步方法执行完成了（详见前面Synchronize中的WaitForSingleObject调用）。}
　　end;
　　SetEvent(SyncProc.signal);
　　end;
　　end;
　　finally
　　LocalSyncList.Free; //等list的序列全部执行完后，释放list的资源 end;
　　finally
　　LeaveCriticalSection(ThreadLock);
　　end;
　　end;
　　至此，整个Synchronize的实现介绍完成。
　　最后来说一下WaitFor，它的功能就是等待线程执行结束。其代码如下：
　　function TThread.WaitFor: LongWord;
　　var
　　H: array[0..1] of THandle;
　　WaitResult: Cardinal;
　　Msg: TMsg;
　　begin
　　H[0] := FHandle;
　　if GetCurrentThreadID = MainThreadID then begin
　　WaitResult := 0;
　　H[1] := SyncEvent;
　　repeat
　　{ This prevents a potential deadlock if the background thread does a SendMessage to the foreground thread }
　　if WaitResult = WAIT_OBJECT_0 + 2 then
　　PeekMessage(Msg, 0, 0, 0, PM_NOREMOVE);
　　WaitResult := MsgWaitForMultipleObjects(2, H, False, 1000, QS_SENDMESSAGE);
　　CheckThreadError(WaitResult <>WAIT_FAILED);
　　if WaitResult = WAIT_OBJECT_0 + 1 then
　　CheckSynchronize;
　　until WaitResult = WAIT_OBJECT_0;
　　end else
　　WaitForSingleObject(H[0], INFINITE);
　　CheckThreadError(GetExitCodeThread(H[0], Result));
　　end;
　　如果不是在主线程中执行WaitFor的话，很简单，只要调用WaitForSingleObject等待此线程的Handle为Signaled状态即可。
　　如果是在主线程中执行WaitFor则比较麻烦。首先要在Handle数组中增加一个SyncEvent，然后循环等待，直到线程结束（即MsgWaitForMultipleObjects返回WAIT_OBJECT_0，详见MSDN中关于此API的说明）。
　　在循环等待中作如下处理：如果有消息发生，则通过PeekMessage取出此消息（但并不把它从消息循环中移除），然后调用MsgWaitForMultipleObjects来等待线程Handle或SyncEvent出现Signaled状态，同时监听消息（QS_SENDMESSAGE参数，详见MSDN中关于此API的说明）。可以把此API当作一个可以同时等待多个Handle的WaitForSingleObject。如果是SyncEvent被SetEvent（返回WAIT_OBJECT_0 + 1），则调用CheckSynchronize处理同步方法。
　　为什么在主线程中调用WaitFor必须用MsgWaitForMultipleObjects，而不能用WaitForSingleObject等待线程结束呢？因为防止死锁。由于在线程函数Execute中可能调用Synchronize处理同步方法，而同步方法是在主线程中执行的，如果用WaitForSingleObject等待的话，则主线程在这里被挂起，同步方法无法执行，导致线程也被挂起，于是发生死锁。
　　而改用WaitForMultipleObjects则没有这个问题。首先，它的第三个参数为False，表示只要线程Handle或SyncEvent中只要有一个Signaled即可使主线程被唤醒，至于加上QS_SENDMESSAGE是因为ynchronize是通过消息传到主线程来的，所以还要防止消息被阻塞。这样，当线程中调用Synchronize时，主线程就会被唤醒并处理同步调用，在调用完成后继续进入挂起等待状态，直到线程结束。
　　至此，对线程类TThread的分析可以告一个段落了，对前面的分析作一个总结：
　　1、 线程类的线程必须按正常的方式结束，即Execute执行结束，所以在其中的代码中必须在适当的地方加入足够多 的对Terminated标志的判断，并及时退出。如果必须要“立即”退出，则不能使用线程类，而要改用API或RTL函数。
　　2、 对可视VCL的访问要放在Synchronize中，通过消息传递到主线程中，由主线程处理。
　　3、 线程共享数据的访问应该用临界区进行保护（当然用Synchronize也行）。
　　4、 线程通信可以采用Event进行（当然也可以用Suspend/Resume）。
　　5、 当在多线程应用中使用多种线程同步方式时，一定要小心防止出现死锁。
　　6、 等待线程结束要用WaitFor方法。

本文转自
http://hi.baidu.com/dareny/blog/item/5af95234b789d0385bb5f58e.html