本文試著從分析Synchronize同步執行的實現機制入手，來解決DLL/ActiveForm中執行緒同步的問題。
執行緒中進行同步時呼叫的Synchronize函式，僅僅是把呼叫呼叫執行緒、呼叫方法地址、異常物件封裝在一個同步結構中，然後呼叫處理同步結構的類方法Synchronize。
procedure TThread.Synchronize(Method: TThreadMethod);
begin
  FSynchronize.FThread := Self;
  FSynchronize.FSynchronizeException := nil;
  FSynchronize.FMethod := Method;
  Synchronize(@FSynchronize);
end;

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); // 建立一個未命名事件，用於主執行緒執行同步的過程結束時通知等待執行緒
    try
      EnterCriticalSection(ThreadLock); // 進入ThreadLock關鍵區，用於保護對Classes單元的全域性變數SyncList的訪問和進行一些呼叫的同步
      try
        if SyncList = nil then
          SyncList := TList.Create;
        SyncProc.SyncRec := ASyncRec;
        SyncList.Add(@SyncProc); // 把要同步的結構新增到列表SyncList中，等待主執行緒取出執行同步過程程式碼
        SignalSyncEvent; // 呼叫SetEvent(SyncEvent)使同步事件SyncEvent處於訊號狀態，主要用在正確處理執行緒結束時
        if Assigned(WakeMainThread) then
          WakeMainThread(SyncProc.SyncRec.FThread); // 關鍵！Classes.WakeMainThread就是Application.WakeMainThread，通過PostMessage發個WM_NULL空訊息，讓主執行緒醒來
        LeaveCriticalSection(ThreadLock); // 離開關鍵區，因為主執行緒呼叫的過程CheckSynchronize中會在取出SyncList列表同步結構前先進入關鍵區的
        try
          WaitForSingleObject(SyncProc.Signal, INFINITE); // 等待主執行緒同步呼叫結束通知事件
        finally
          EnterCriticalSection(ThreadLock);
        end;
      finally
        LeaveCriticalSection(ThreadLock);
      end;
    finally
      CloseHandle(SyncProc.Signal);
    end;
    if Assigned(ASyncRec.FSynchronizeException) then raise ASyncRec.FSynchronizeException;
  end;
end;
在主執行緒的訊息處理過程WndProc中檢索到WM_NULL訊息就會呼叫CheckSynchronize對同步列表SyncList中的同步結構進行逐個處理，直至SyncList中要同步的方法全部被同步呼叫完畢。而在應用程式空閒時也會呼叫CheckSynchronize進行同步處理。
procedure TApplication.WndProc(var Message: TMessage);
begin
  try
    (略)
    with Message do
      case Msg of
        WM_NULL:
          CheckSynchronize;
      else
        Default;
      end;
  except
    HandleException(Self);
  end;
end;
procedure TApplication.Idle(const Msg: TMsg);
begin
  (略)
  if (GetCurrentThreadID = MainThreadID) and CheckSynchronize then
    Done := False;
  if Done then WaitMessage;
end; 
再看一下Delphi封裝的實際執行緒執行體函式：
function ThreadProc(Thread: TThread): Integer;
var
  FreeThread: Boolean;
begin
  try
    if not Thread.Terminated then
    try
      Thread.Execute;
    except
      Thread.FFatalException := AcquireExceptionObject;
    end;
  finally
    FreeThread := Thread.FFreeOnTerminate; // 是否執行緒執行結束後自動釋放Thread物件例項？
    Result := Thread.FReturnValue;
    Thread.DoTerminate; // 這裡呼叫Synchronize(CallOnTerminate)，也就是說OnTerminate事件程式碼實際上是在主執行緒中同步執行的
    Thread.FFinished := True;
    SignalSyncEvent; // 使同步事件SyncEvent處於訊號狀態，使執行緒Destory呼叫WaitFor時如果是主執行緒，可以進行必要的同步處理
    if FreeThread then Thread.Free; // 注意：執行緒Destroy部分的程式碼是線上程執行體中執行的
    EndThread(Result);
  end;
end;

到這裡我們基本清楚了Synchronize同步的實現機制：
執行緒將同步執行緒、方法封裝成同步結構，新增到同步列表SyncList中，然後傳送WM_NULL訊息喚醒主執行緒，然後呼叫WaitForSingleObject掛起等待主執行緒處理。主執行緒處理WM_NULL訊息或在空閒時呼叫CheckSynchronize，從同步列表SyncList取出同步結構，在主執行緒中呼叫執行同步方法，執行完畢通過同步結構中的未命名事件控制代碼通知等待執行緒。等待執行緒收到事件通知後醒來，然後繼續執行。

以上是對通常的應用程式中的執行緒Synchronize同步實現機制的分析，而對於DLL中的執行緒在用Synchronize進行同步時又有它的特殊性。
DLL中的全域性變數是每個DLL都複製一份的，各個DLL之間以及DLL與主程式之間不能直接進行資料共享。這也就是說主程式的SyncEvent、SyncList、ThreadLock與DLL中的SyncEvent、SyncList、ThreadLock變數是不一樣的。因此在DLL中的Synchronize同步，使用到的是DLL中的SyncEvent、SyncList、ThreadLock等變數，因此，直接使用Synchronize，主程式的CheckSynchronize就無法對DLL中的執行緒進行同步排程執行。而DLL中的Application卻從來沒有執行Run進入訊息迴圈，因此也不能呼叫CheckSynchronize來處理執行緒的同步。因此在DLL中就需要主動呼叫CheckSynchronize函式來對同步列表SyncList進行處理。可以在DLL中專門建立一個視窗，在視窗訊息迴圈中處理WM_NULL訊息，呼叫ChechSynchronize即可。
while PeekMessage(Msg, 0, 0, 0, PM_REMOVE) do
  if Msg.message = WM_NULL then
    CheckSynchronize
  else
  begin
    TranslateMessage(Msg);
    DispatchMessage(Msg);
  end;

對ActiveForm中使用的執行緒呼叫Synchronize的情況也大體上相同，它的宿主程序是瀏覽器(如IE)，IE一來不是Delphi編的程式，不會在主程式訊息迴圈主呼叫CheckSynchronize進行同步處理的；二來即使它進行同步處理，也不是採用Delphi的同步實現方法，沒有SyncList、SyncEvent、ThreadLock等變數的使用的；另外，ActiveForm由於是個OCX(實際上是種DLL)，因此還有如同上述DLL中執行緒同步的問題，解決辦法也可以和上面一樣。當然，應該也可以直接在ActiveForm中新增處理WM_NULL訊息的處理過程，呼叫CheckSynchronize進行同步處理，我沒有進行試驗，具體地，你可以親自試一下。