Синхронная/асинхронная модель

Интерактивный характер телефонии требует, чтобы 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 перечислены состояния, которые выполняются синхронно или асинхронно.