Model Sinkron/Asinkron

Sifat interaktif telepon mengharuskan TAPI menjadi lingkungan operasi real time. Banyak fungsi TAPI diperlukan untuk menyelesaikan dengan cepat dan mengembalikan hasilnya ke aplikasi secara sinkron. Fungsi lain (seperti memutar nomor) mungkin tidak dapat diselesaikan secepat dan karenanya beroperasi secara asinkron.

Operasi telepon selesai baik secara sinkron atau asinkron. Kedua model ini berbeda sebagai berikut. Fungsi sinkron menjalankan seluruh permintaan sebelum utas pemanggil diizinkan untuk kembali dari panggilan fungsi. Fungsi asinkron kembali sebelum permintaan dijalankan secara keseluruhan. Ketika permintaan asinkron nanti selesai, penyedia layanan melaporkan penyelesaian dengan memanggil prosedur panggilan balik yang awalnya diberikan TAPI kepadanya di awal urutan inisialisasi.

• Operasi asinkron memiliki parameter bernama dwRequestID dari jenis yang ditentukan DRV_REQUESTID sebagai parameter pertamanya. Operasi semacam itu melakukan bagian dari pemrosesannya dalam panggilan fungsi dan sisa pemrosesannya dalam utas eksekusi independen setelah panggilan fungsi kembali. Ketika fungsi kembali, fungsi mengembalikan hasil kesalahan negatif atau (positif) dwRequestID yang diteruskan dalam panggilan fungsi. Hasil kesalahan negatif menunjukkan bahwa operasi selesai (dan gagal). positif dwRequestID yang dikembalikan menunjukkan bahwa operasi berlanjut di utas independen. Dalam kasus seperti itu, penyedia layanan akhirnya memanggil prosedur ASYNC_COMPLETION, melewati dwRequestID dan kode hasil untuk menunjukkan hasil operasi. Kode hasil adalah nol untuk keberhasilan atau salah satu dari kumpulan hasil kesalahan (negatif) yang sama. Bagaimanapun, penyedia layanan tidak boleh mengembalikan nol atau nilai positif apa pun selain dwRequestID dari fungsi yang ditunjuk sebagai asinkron karena dapat menghasilkan hasil yang tidak terduga. Penyedia layanan harus selalu menyalin data input dari memori aplikasi ke memori penyedia layanan sebelum kembali dari fungsi asinkron.
• Operasi sinkron tidak memiliki dwRequestID sebagai parameter pertamanya. Operasi semacam itu melakukan semua pemrosesannya dalam utas eksekusi pemanggil, mengembalikan hasil akhir saat dikembalikan. Hasilnya adalah nol untuk keberhasilan atau kode kesalahan negatif untuk kegagalan. Penyedia layanan tidak memanggil ASYNC_COMPLETION untuk operasi sinkron.

Sangat menarik untuk mempertimbangkan waktu panggilan balik "penyelesaian" relatif terhadap ketika permintaan asli kembali. Permintaan asinkron umum akan diterapkan oleh penyedia layanan seperti dalam pseudocode berikut:

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
}

Jika operasi selesai dengan sangat cepat (atau permintaan asli kembali sangat lambat), ada kemungkinan bahwa handler interupsi yang berjalan ketika operasi fisik selesai dapat dipicu sebelum permintaan asli kembali ke aplikasi atau bahkan ke TAPI. Perilaku ini diperbolehkan. TAPI menjamin bahwa pemberitahuan penyelesaian akhir ke aplikasi dikirimkan setelah permintaan asli kembali.

TAPI 2.x: Mencantumkan status mana yang menyatakan apakah setiap fungsi selesai secara sinkron atau asinkron muncul di Referensi Fungsi Cepat TAPI.