2.4. SRL Asynchronous Programming

In asynchronous programming, the calling thread performs further operations while the Dialogic function completes. At completion, the application receives event notification. Asynchronous programming is recommended for applications that require coordination of multiple tasks and have large numbers of devices. Asynchronous programming uses system resources more efficiently because it controls multiple devices in a single thread. On the other hand, synchronous programming requires a separate thread for each Dialogic device.

Due to concurrent processing requirements, a thread cannot block execution while waiting for Dialogic functions, such as dx_play( ) or dx_record( ), to finish; this would interfere with the processing requirements of other devices being managed by the thread. In this case, the SRL lets you create an event-driven state machine for each device. Instead of each Dialogic function blocking until completion, it returns immediately and allows thread processing to continue. Subsequently, when an event is returned through the SRL, signifying the completion of the Dialogic operation, state machine processing can continue.

You can also place user-defined events into the Dialogic event queue to get single-point state processing control of non-Dialogic application states.

IIn summary, asynchronous programming:

• Achieves a high level of resource management by combining multiple Dialogic devices in a single thread.
• Provides better control of applications that have high channel density.
• Provides several extended mechanisms that help you port Dialogic applications from other operating systems.
• Works with other SRL mechanisms that allow new developers to tightly integrate the SRL with standard Windows 32-bit programming mechanisms, such as the Win32 API and MFC.
• Reduces system overhead by minimizing thread context switching.
• Simplifies the coordination of events from many Dialogic devices.

Click here to contact Dialogic Customer Engineering