Modello sincrono/asincrono

La natura interattiva della telefonia richiede che TAPI sia un ambiente operativo in tempo reale. Molte delle funzioni TAPI sono necessarie per completare rapidamente e restituire i risultati all'applicazione in modo sincrono. Altre funzioni ( ad esempio la composizione) potrebbero non essere in grado di completare il più rapidamente e quindi operare in modo asincrono.

Le operazioni di telefonia vengono completate in modo sincrono o asincrono. Questi due modelli differiscono come indicato di seguito. funzioni sincrone eseguire l'intera richiesta prima che il thread del chiamante venga restituito dalla chiamata di funzione. funzioni asincrone restituite prima dell'esecuzione della richiesta nel suo insieme. Al termine della richiesta asincrona, il provider di servizi segnala il completamento chiamando una routine di callback che TAPI ha originariamente fornito all'utente all'inizio della sequenza di inizializzazione.

• Le operazioni asincrone hanno un parametro denominato dwRequestID del tipo definito DRV_REQUESTID come primo parametro. Tale operazione esegue parte dell'elaborazione nella chiamata di funzione e il resto dell'elaborazione in un thread di esecuzione indipendente dopo la restituzione della chiamata di funzione. Quando la funzione viene restituita, restituisce un risultato di errore negativo o il dwRequestID passato nella chiamata di funzione. Il risultato negativo dell'errore indica che l'operazione è stata completata (e non è riuscita). Il positivo dwRequestID restituito indica che l'operazione continua nel thread indipendente. In tal caso, il provider di servizi chiama infine la routine ASYNC_COMPLETION, passando il dwRequestID e un codice di risultato per indicare il risultato dell'operazione. Il codice di risultato è zero per l'esito positivo o uno dello stesso set di risultati dell'errore (negativo). In ogni caso, il provider di servizi non deve mai restituire zero o alcun valore positivo diverso da dwRequestID da una funzione designata come asincrona perché ciò può produrre risultati imprevisti. I provider di servizi devono sempre copiare i dati di input dalla memoria dell'applicazione nella memoria del provider di servizi prima di restituire da una funzione asincrona.
• Le operazioni sincrone non hanno dwRequestID come primo parametro. Tale operazione esegue tutta l'elaborazione nel thread di esecuzione del chiamante, restituendo il risultato finale quando viene restituito. Il risultato è zero per l'esito positivo o un codice di errore negativo per l'errore. Il provider di servizi non chiama ASYNC_COMPLETION per le operazioni sincrone.

È interessante considerare la tempistica di un callback di "completamento" rispetto alla restituzione della richiesta originale. Una tipica richiesta asincrona viene implementata dal provider di servizi come nello pseudocodice seguente:

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
}

Se l'operazione viene completata molto rapidamente (o la richiesta originale restituisce molto lentamente), è possibile che il gestore di interrupt eseguito quando un'operazione fisica viene completata può essere attivata prima che la richiesta originale torni all'applicazione o persino a TAPI. Questo comportamento è consentito. TAPI garantisce che la notifica di completamento finale all'applicazione venga recapitata dopo la restituzione della richiesta originale.

TAPI 2.x: Elenca gli stati che indicano se ogni funzione viene completata in modo sincrono o asincrono in riferimento a funzioni rapide TAPI.