次の方法で共有

同期/非同期モデル

  • [アーティクル]

テレフォニーの対話型の性質では、TAPI をリアルタイムの運用環境にする必要があります。 TAPI 関数の多くは、迅速に完了し、その結果をアプリケーションに同期的に返す必要があります。 その他の機能 (ダイヤルなど) は、すぐに完了できないため、非同期的に動作する可能性があります。

テレフォニー操作は、同期的または非同期的に完了します。 これら 2 つのモデルは、次のように異なります。 同期関数は 、呼び出し元のスレッドが関数呼び出しから戻ることを許可される前に、要求全体を実行します。 非同期関数 は、要求全体が実行される前に を返します。 非同期要求が後で完了すると、サービス プロバイダーは、TAPI が初期化シーケンスの早い段階で最初に指定したコールバック プロシージャを呼び出して、完了を報告します。

  • 非同期操作には、最初のパラメーターとしてDRV_REQUESTID定義された型の dwRequestID という名前のパラメーターがあります。 このような操作は、関数呼び出しで処理の一部を実行し、その処理の残りの部分は、関数呼び出しが返された後に独立した実行スレッドで実行します。 関数が戻ると、負のエラー結果または関数呼び出しで渡された (正の) dwRequestID が返されます。 負のエラー結果は、操作が完了 (および失敗) したことを示します。 返される正の dwRequestID は、独立したスレッドで操作が続行されることを示します。 このような場合、サービス プロバイダーは最終的に ASYNC_COMPLETION プロシージャを呼び出し、 dwRequestID と結果コードを渡して操作の結果を示します。 成功した場合は結果コードが 0 であるか、同じ (負の) エラー結果のセットのいずれかです。 いずれの場合も、サービス プロバイダーは、非同期として指定された関数から 0 または dwRequestID 以外の 正の値を返す必要はありません。これは、予期しない結果が発生する可能性があるためです。 サービス プロバイダーは、非同期関数から戻る前に、常にアプリケーション メモリからサービス プロバイダー メモリに入力データをコピーする必要があります。
  • 同期操作には、最初のパラメーターとして dwRequestID がありません。 このような操作は、呼び出し元の実行スレッドですべての処理を実行し、返されたときに最終的な結果を返します。 成功した場合は 0、失敗の場合は負のエラー コードになります。 サービス プロバイダーは、同期操作 の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 クイック関数リファレンスに表示されます。