Modelo síncrono/assíncrono

A natureza interativa da telefonia requer que o TAPI seja um ambiente operacional em tempo real. Muitas das funções TAPI são necessárias para serem concluídas rapidamente e retornar seus resultados para o aplicativo de forma síncrona. Outras funções (como discagem) podem não ser capazes de ser concluídas tão rapidamente e, portanto, operar de forma assíncrona.

As operações de telefonia são concluídas de forma síncrona ou assíncrona. Esses dois modelos diferem da seguinte maneira. As funções síncronas executam toda a solicitação antes que o thread do chamador possa retornar da chamada de função. As funções assíncronas retornam antes que a solicitação seja executada em sua totalidade. Quando a solicitação assíncrona for concluída posteriormente, o provedor de serviços relatará a conclusão chamando um procedimento de retorno de chamada que TAPI originalmente forneceu a ela no início da sequência de inicialização.

• As operações assíncronas têm um parâmetro chamado dwRequestID do tipo definido DRV_REQUESTID como seu primeiro parâmetro. Essa operação executa parte de seu processamento na chamada de função e o restante de seu processamento em um thread de execução independente após o retorno da chamada de função. Quando a função retorna, ela retorna um resultado de erro negativo ou o dwRequestID (positivo) que foi passado na chamada de função. O resultado do erro negativo indica que a operação foi concluída (e falhou). O dwRequestID positivo retornado indica que a operação continua no thread independente. Nesse caso, o provedor de serviços eventualmente chama o procedimento ASYNC_COMPLETION , passando o dwRequestID e um código de resultado para indicar o resultado da operação. O código de resultado é zero para êxito ou um dos mesmos resultados de erro (negativos). De qualquer forma, o provedor de serviços nunca deve retornar zero ou qualquer valor positivo diferente de dwRequestID de uma função designada como assíncrona porque isso pode produzir resultados inesperados. Os provedores de serviço sempre devem copiar dados de entrada da memória do aplicativo para a memória do provedor de serviços antes de retornar de uma função assíncrona.
• As operações síncronas não têm dwRequestID como seu primeiro parâmetro. Essa operação executa todo o processamento no thread de execução do chamador, retornando o resultado final quando ele retorna. O resultado é zero para êxito ou um código de erro negativo para falha. O provedor de serviços não chama ASYNC_COMPLETION para operações síncronas.

É interessante considerar o tempo de um retorno de chamada de "conclusão" em relação a quando a solicitação original retorna. Uma solicitação assíncrona típica seria implementada pelo provedor de serviços como no seguinte pseudocódigo:

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 a operação for concluída muito rapidamente (ou a solicitação original retornar muito lentamente), é possível que o manipulador de interrupção executado quando uma operação física for concluída possa ser disparado antes que a solicitação original retorne ao aplicativo ou até mesmo ao TAPI. Esse comportamento é permitido. O TAPI garante que a notificação de conclusão eventual para o aplicativo seja entregue após o retorno da solicitação original.

TAPI 2.x: Lista o estado em que cada função é concluída de forma síncrona ou assíncrona na Referência de Função Rápida do TAPI.