IBM
Contents Index Previous Next



Introduction


The code that is generated by the Cadvanced SDL to C compiler is designed to run on different platforms. This is done by letting all platform dependent concepts be represented by C macros that can be expanded appropriately for each environment. There are also types used in the generated code that have to be defined. Integration, as referred to in this chapter, is the process of adapting the generated code to a certain platform.

This chapter describes the different models that are supported in SDL Suite.

Note:

Throughout this chapter, annexes excluded, VxWorks terminology has been used whenever there are differences between operating systems. Particularly, this means that the term task has been used on several occasions. The corresponding term would be thread for Win32 and Solaris, process for OSE Delta, and task for Nucleus.

Different Integration Models

With Cadvanced, there are three different run-time models, called Light Integration, Threaded Integration and Tight Integration. Tight integrations are then divided into two submodels, the Standard model and the Instance-Set model. All models use the same generated code.

You will find descriptions of the different models below, as well as guidelines for choosing between them.

Light integration

The simplest case is called a Light integration because only a minimum of interaction with the operating system is required; a Light integration could even run on a target system without any OS at all.

The complete SDL system runs as a single OS task. Scheduling of SDL processes is handled by the standard kernel, running a complete state transition at a time (no preemption). Worst case scheduling latency is thus the duration of the longest transition.

Communication between SDL processes is handled by the kernel; communication between the SDL system and the environment is handled in the two user supplied functions xInEnv() and xOutEnv(). These functions are platform dependent. See Figure 567.

Figure 567 : Signalling in the Light Integration Model.

An SDL process sends one internal and one external signal. xOutEnv() must be written to call the OS send primitive. Thick borders denote OS tasks.

Other properties of a Light Integration:

Threaded Integration

The main difference between a Light integration and a Threaded integration is that any part of the SDL system can execute in its own thread in a Threaded integration. A thread in a Threaded integration can execute one or several SDL processes or even blocks. How the different SDL objects should be mapped to threads is specified in the Deployment Editor. The user can specify thread-specific parameters like: STACKSIZE, PRIORITY, MAXMESSAGEQUEUESIZE and MAXMESSAGESIZE in the Deployment Editor. The Deployment Editor works together with the Targeting Expert to generate a Threaded integration.

Note:

A Threaded integration can only be generated using the Deployment Editor and the Targeting Expert, i.e. the make feature in the Organizer CANNOT be used.

Communication and execution control in one thread is handled by the SDL kernel and not the OS kernel. See Figure 568. This model shows the default Threaded integration where OS semaphores are the only OS primitives used in the signal sending. The xMainLoop() function is the entry point for each thread.

Figure 568 : Signalling in Threaded Integration.

SDL Kernel functions are used for sending signals within or between threads. Thick borders denote threads.

Semaphores are used frequently in Threaded to protect globally accessible data like input queues and export queues. Semaphores are also used in the start-up to synchronize the execution of newly created threads. We must ensure that no thread is allowed to start executing until ALL threads have been created in the start-up phase.

Communication with external threads (Threads not made from SDL specifications) is handled by the environment functions in the same way as for a Light integration. There is though one major difference and that is that it is possible in a Threaded to send signals directly to an SDL process with the SDL_Output() function. The SDL_Output() function is "thread-safe" because of the use of OS semaphores.

Variations of Threaded Integration

There are two different implementation of signal sending between threads in Threaded. The default model send signals in the same way as in a Light integration but the input queues are protected by OS semaphores. In the alternative model, the signals are sent/received by OS_Send and OS_Received. In the alternative model there is no use for OS semaphores. Which model to use can be decided at compilation time by setting the compilation switch THREADED_ALTERNATIVE_SIGNAL_SENDING.

Threaded Default

The sender of an SDL signal "takes" a semaphore before accessing the receivers input queue. The signal is then linked into the input queue and the semaphore is "given" back.

The receiver is normally "waiting" for a semaphore. When a signal is sent, the semaphore is "released" by the sender. To send a signal, two semaphores are normally needed. One semaphore is protecting the input queue and the other is used for synchronizing the sender and the receiver. In Solaris, where we use POSIX threads and semaphores they are called: xInputPortMutex and xInputPortCond.

One OS feature that is needed in Threaded is a "Conditional Wait". We are only allowed to wait for a signal until the first internal timer expires. In POSIX, there is a primitive called pthread_cond_wait() and in Windows there is a similar concept called WaitForSingleObject() where a time-out can be specified. In VxWorks and OSE, the only concept where you can specify a time-out is OS_Receive. For synchronization between the sender and receiver we are sending a small OS_Message (the character `c') in these two RTOS.

Threaded using OS Send and OS Receive

In this alternative implementation we are sending the signals using OS_Send and OS_Receive. Signals are now sent to OS_Message queues. The sender sends the pointer to the SDL signal in an OS_Message to the receiver's OS_Queue. When the signal is received, the SDL signal is unpacked and linked in to the receivers input queue. The advantage with this implementation is that there is now synchronization between the sender and the receiver. Any number of threads can send signals at the same time to a specific receiver without having to wait for a semaphore.

Tight integration

We also provide an alternate run-time model, which is called a Tight integration because the generated code interacts directly with the underlying operating system when creating processes, sending signals, etc.

The SDL processes run as separate OS tasks as explained below. Scheduling is handled by the OS and is normally time-sliced, priority based and preemptive.

Communication takes place using the inter-process communications mechanisms offered by the OS, normally message queues. This applies to signals sent between SDL processes as well as signals sent to or received from the environment. There are no environment functions, as illustrated in Figure 569.

Figure 569 : Signalling in the Tight Integration Model.

An SDL process sends one internal and one external signal. OS primitives are always used. The SDL system is not an entity of its own. Thick borders denote OS tasks.

Other properties of a Tight Integration:

Variations on Tight integration

Tight integrations come in two varieties, the Standard model and the Instance-Set model. Consider an SDL system with processes as outlined in Figure 570.

Figure 570 : A partial SDL system

This system will be used for explaining the different models of Tight Integration.

Tight Standard

In the standard model of a Tight integration every SDL process instance is mapped to its own OS task. Tasks are created and destroyed dynamically as SDL process instances are created and terminated.

The example system will initially run as five OS tasks (four for Prs1, and one for Prs2). Up to 13 tasks may be created as needed.

Tight Instance-Set

In the Instance-Set model of a Tight integration every SDL process instance set is mapped to its own OS task. Tasks are created statically when the SDL system is initialized and are never destroyed. Thus there may be OS tasks that have no SDL process instances to run.

The example system will run as three OS tasks regardless of the number of process instances (one task each for Prs1, Prs2 and Prs3).

Choosing between Light, Threaded and Tight Integration

Choosing between the three integration models depends on many factors. Some of them are related to properties of the SDL system, others relate to the target environment. Important factors to consider are:

Performance vs. scheduling latency

Generally, the Light integration model provides better performance than a Tight integration, but worst-case scheduling latency is the duration of the longest state transition.

A Tight integration is normally preferable when low scheduling latency is important. On the other hand, performance suffers from the overhead associated with OS scheduling and inter-process communications.

Another consideration is that blocking calls (either inlined in SDL code or as part of environment functions) will completely stop execution of a Light integration for the duration of the call. Making blocking calls in a Tight integration will only stop the thread making the call.

The Threaded integration is in a sense a combination of the other two integration models. An application part that makes blocking calls can be mapped to a separate OS thread. Other parts, where fast inter-process communication is important, can be mapped to another OS thread. Internally in this thread, signal exchange will be handled in the same way as in a Light integration.

Environment interaction

If interaction with the environment is simple then a Light integration is the best choice, especially if the system sends many signals and receives few. You can generate templates for the environment functions from the SDL Suite and just add code for converting between the signal representation and the actual environment hardware or software.

If interaction with the environment is complex then a Tight integration is probably the easiest to use, since you only need to interface to the operating system queues. This is the case if you need process behavior in the interaction (for example, to establish a communications session before sending the signal).

Other cases where a Tight integration might be the best choice are

In a Threaded integration, the integration with the environment should normally be handled in the environment functions in the same way as for a Light integration. It is possible though in Threaded to send signals directly to an SDL process with the SDL_Output() function without involving the xInEnv() function.

Operating system issues

If you will not use an OS at all then you have to select a Light integration. In addition, you will have to provide some simple functions for getting system time and handling memory allocation (depending on compiler and libraries, standard C library functions can often be used).

If you use an OS that takes care of load balancing between CPUs then you should select a Tight integration, because load balancing normally uses threads as the load unit to distribute.

If you want to distribute your SDL System over several nodes (CPUs) you should use the Threaded integration together with the TCP/IP feature.

Considerations when choosing between Tight and Threaded

Overall, IBM Rational recommends using the Threaded integration mode, unless there are specific technical reasons to prefer one of the other integration models.

The two most important reasons for choosing the Threaded model are:

  1. The Threaded integration out-perform a Tight Integration in most situations, e g implementation of Timers and creation of tasks is about 100% faster in Threaded.
  2. In Threaded you are not limited to two partitioning models. Any mapping between SDL objects and threads can be specified in the Deployment editor.

For a more comprehensive list of the differences between Threaded and Tight see the following sections.

Advantages of Threaded
Advantages of Tight
Disadvantages of Threaded
Disadvantages of Tight
1

The MSC trace will be printed on standard output. To see the trace in an MSC diagram, copy the text into a file and read it into the MSC Editor.


http://www.ibm.com/rational
Contents Index Previous Next