同步/非同步模型

電話語音的互動式本質需要 TAPI 是即時操作環境。 許多 TAPI 函式都需要快速完成，並以同步方式將其結果傳回給應用程式。 其他函式 (例如撥號) 可能無法快速完成，因此以非同步方式運作。

電話語音作業會以同步或非同步方式完成。 這兩個模型不同，如下所示。 同步函式 會先執行整個要求，再允許呼叫端的執行緒從函式呼叫傳回。 非同步函式 會在要求完全執行之前傳回。 當非同步要求稍後完成時，服務提供者會呼叫 TAPI 最初在初始化順序中提供給它的回呼程式，以報告完成。

• 非同步作業具有名為 dwRequestID 的參數，其定義類型 DRV_REQUESTID 為其第一個參數。 這類作業會在函式呼叫中執行部分處理，並在函式呼叫傳回之後，在獨立執行執行緒中執行其餘部分的處理。 當函式傳回時，它會傳回負誤差結果或 (正) 在函式呼叫中傳遞的 dwRequestID 。 負錯誤結果表示作業已完成 (且失敗) 。 傳回的正 dwRequestID 表示作業會繼續在獨立執行緒中。 在這種情況下，服務提供者最終會呼叫 ASYNC_COMPLETION 程式，並傳遞 dwRequestID 和結果碼來指出作業的結果。 結果碼為零，表示成功，或一組相同的 (負) 錯誤結果之一。 在任何情況下，服務提供者絕不會從指定為非同步函式傳回零或 非 dwRequestID 以外的任何正值，因為這樣做可能會產生非預期的結果。 服務提供者應該一律先將輸入資料從應用程式記憶體複製到服務提供者記憶體，再從非同步函式傳回。
• 同步作業沒有 dwRequestID 作為其第一個參數。 這類作業會在呼叫端的執行執行緒中執行其所有處理，並在傳回時傳回最終結果。 成功的結果為零，或失敗的負錯誤碼。 服務提供者不會針對同步作業呼叫 ASYNC_COMPLETION 。

考慮相對於原始要求傳回時「完成」回呼的時間很有趣。 服務提供者會實作典型的非同步要求，如下列虛擬程式碼所示：

Some_request(Request_ID, ...) {
  check parameters for validity
  check device state for validity
  store Request_ID for Completion Interrupt Handler's use
  manipulate device registers to start physical operation
  return Request_ID  // to indicate asynch operation
}
Operation Completion Interrupt Handler: {
  if operation was successful then
    call "completion" callback passing Request_ID and "success"
  else
    call "completion" callback passing Request_ID and "error num"
  endif
}

如果作業快速完成， (或原始要求傳回的速度非常慢) ，則可能會在原始要求回到應用程式或甚至 TAPI 之前觸發實體作業完成時執行的中斷處理常式。 允許此行為。 TAPI 保證在原始要求傳回之後，會傳遞應用程式的最終完成通知。

TAPI 2.x： 列出每個函式在 TAPI 快速函式參考中同步或非同步完成的狀態。