2.2.1 Synchronous Mode Programming

Synchronous mode programming is characterized by functions that block thread execution until the function completes or a failed or error message is returned. The operating system can put individual device threads to sleep while allowing other device threads to continue their actions unabated. Thus, a synchronous function waits for a completion indication from the firmware or driver before returning control to the thread. Since further execution is blocked by a synchronous function, a separate thread is needed for each channel or task. When an Intel® Dialogic® function completes, the operating system wakes up the function's thread so that processing continues. A termination event is not generated for a synchronous function.

The Windows synchronous programming model is recommended for less complex applications where only a limited number of channels and calls will be handled and processor loading remains light. The synchronous model should be used only for simple and straight flow control applications with only one action per device occurring at any time.

A synchronous model application can handle multiple channels by structuring the application as a single-channel application and then creating a separate synchronous thread for each channel. For example, for a 60 channel application, the application creates 60 synchronous threads, one thread to handle each of the 60 channels. The application would not need event-driven state machine processing because each Intel® Dialogic function runs uninterrupted to completion. Since this model calls functions synchronously, it is less complex than a corresponding asynchronous model application. However, since synchronous applications imply the creation of a thread or a process for each channel used, these applications tend to slow down the response of the system and to require a high level of system resources (that is, they increase processor loading) to handle each channel. This can limit maximum device density, providing limited scalability for growing systems.

When using the synchronous model, unsolicited events are not processed until the thread calls an Intel® Dialogic function such as gc_GetMetaEvent( ), dx_getevt( ) or dt_getevt( ). Unsolicited events can be handled as follows:

• By creating a separate asynchronous thread with event handlers, see Section 2.2.2.2, "Asynchronous Model with Event Handlers". For example, the synchronous application would first create an asynchronous thread to handle all unsolicited events and then the application could create synchronous threads, one for each channel, to process the calls on each channel. The asynchronous thread uses the sr_waitevt( ) function to do a blocking call. When an unsolicited event occurs, the asynchronous unsolicited event-processing thread identifies the event to a device, services the event and notifies the synchronous thread controlling the device of the action taken. When the application runs an unsolicited events asynchronous thread, the event processing thread internal to the SRL should be disabled by setting the SR_MODELTYPE value of the sr_setparm( ) function's parmno parameter to SR_STASYNC.
• By enabling event handler(s) within the application before creating the synchronous threads that handle each channel. For example, the synchronous application would first enable the unsolicited event handler(s) for the device(s) and event(s) and/or for any device, any event. Then the application would create synchronous threads, one for each channel, to process the calls on each channel. When an unsolicited event specified by an enabled event handler occurs, the SRL passes the unsolicited event information to the application. When the application uses the unsolicited event handler(s) approach, the event processing thread internal to the SRL must be enabled (default). The SRL event processing thread can also be enabled by setting the SR_MODELTYPE value of the sr_setparm( ) function's parmno parameter to SR_MTASYNC.

Click here to contact Telecom Support Resources