Thread Management in Speech Applications
This content is no longer actively maintained. It is provided as is, for anyone who may still be using these technologies, with no warranties or claims of accuracy with regard to the most recent product version or service release.
In applications that are built using Speech Server, authors should be cautious when creating new threads or calling methods on other threads.
Creating Threads in a Voice Response Application
Voice response application activities help ensure that the right thread is executing at all times. Authors need to be aware of possible difficulties when they create new threads, especially inside new activities.
There are some constraints due to Windows Workflow Foundation. Some methods, for example methods that close an activity, can only be called from threads that are known to Windows Workflow Foundation. If you try to access these methods without first getting on the right thread, an exception is thrown.
Calling the Telephony and Speech APIs from Multiple Threads
The Telephony and Speech API is free-threaded, which means that an author can safely call methods from two different threads at the same time, without destabilizing the API. In general though, calling methods from more than one thread is not recommended, and because of this the Telephony and Speech API ensures that only a single event is raised at a time. For example, the SpeakCompleted event is raised and the RecognizeCompleted event is not raised until the author's handler for SpeakCompleted has returned. This allows the author to only deal with a single thread, unless they explicitly create a thread by using a timer, an asynchronous database operation, or some other mechanism.
It is safe for an author to call the Telephony and Speech API from multiple threads, but it is rarely useful. For example, if the author calls the SpeakAsync() method from two threads, the second call does not destabilize the API, but it almost certainly causes an InvalidOperationException to be thrown, because it is not possible to call SpeakAsync() when the Speech Server Synthesizer is active. Similarly, calling a non-workflow method from a workflow method might fail.
In cases where the author is not on the single thread provided by the Telephony and Speech API, for example the author is using a Timer and has code executing in the Timer's expired handler, the author can use the IApplicationHost.QueueEvent() method to have the desired code execute on the normal, single thread. Calling this method, that is passed a delegate, instructs both the Telephony and Speech API and Windows Workflow Foundation to put that delegate onto their queues, along with any events that are already there. When the queue has processed any events added prior to the call to QueueEvent, the author's delegate is invoked and the author can run the desired code on the proper thread.
Any classes that use the AsyncOperationManager class, for example the MessageQueue class, use the correct thread automatically. Speech Server also exposes the IApplicationHost.SynchronizingObject property, which can be used by any class that exposes the ISynchronizeInvoke interface (for example, System.Timers.Timer) so that callbacks come in on the correct thread.