RTOS
A process (synonymously called “task” throughout this text) is an abstraction of a running program and is the logical unit of work schedulable by the real -time operating system. A process is usually represented by a private data structure that contains at least an identity, priority level, state of execution (e.g., running, ready, or suspended), and resources associated with the process. A thread is a lightweight process that must reside within some regular process and make use of the resources of that particular process only. Multiple threads that reside logically within the same process may share resources with each other. Real - time operating systems provide three essential functions with respect to software tasks: scheduling, dispatching, as well as intertask communication and synchronization. The kernel of the operating system is the smallest entity that provides for all these functions. Scheduler: A scheduler determines which task will run next in a multitasking system, while a dispatcher performs the necessary bookkeeping to start that particular task. Moreover, intertask communication and synchronization assures that parallel tasks may cooperate effectively. Four layers of operating system functionality and an associated taxonomy are
shown in Figure 2. The bottom layer of Figure 2, a microkernel, provides for plain task scheduling and dispatching. A kernel also provides for intertask communication and synchronization via mailboxes, queues, pipes, and semaphores. Example: A real - time executive is an extended kernel that includes privatized memory
blocks, input/output services, and other supporting features. Operating system: Operating system is an advanced executive that provides for a generalized user interface, security features, and a sophisticated file management system. There are three broad paradigms for inter-task communications and synchronization: Task-owned facilities – attributes that an RTOS imparts to tasks that provide communication (input) facilities. The example we will look at some more is signals. Kernel objects – facilities provided by the RTOS which represent stand-alone communication or synchronization facilities. Examples include: event flags, mailboxes, queues/pipes, semaphores and murexes. Message passing – a rationalized scheme where an RTOS allows the creation of message objects, which may be sent from one to task to another or to several others. This is fundamental to the kernel design and leads to the description of such a product as being a “message passing RTOS”. Signals : Signals are probably the simplest inter-task communication facility offered in conventional RTOS . They consist of a set of bit flags – there may be 8, 16 or 32, depending on the specific implementation – which is associated with a specific task. Event flag groups are like signals in that they are a bit-oriented inter-task communication facility. They may similarly be implemented in groups of 8, 16 or 32 bits. They differ from signals in being independent kernel objects; they do not “belong” to any specific task. Semaphores are independent kernel objects, which provide a flagging mechanism that is generally used to control access to a resource. There are broadly two types: binary semaphores (that just have two states) and counting semaphores (that have an arbitrary number of states). Some processors support (atomic) instructions that facilitate the easy implementation of binary semaphores. Binary semaphores may also be viewed as counting semaphores with a count limit of 1. Mailboxes are independent kernel objects, which provide a means for tasks to transfer messages. The message size depends on the implementation, but will normally be fixed. One to four pointer-sized items are typical message sizes. Commonly, a pointer to some more complex data is sent via a mailbox. Some kernels implement mailboxes so that the data is just stored in a regular variable and the kernel manages access to it. Mailboxes may also be called “exchanges”, though this name is now uncommon. Ques are independent kernel objects, that provide a means for tasks to transfer messages. They are a little more flexible and complex than mailboxes. The message size depends on the implementation, but will normally be a fixed size and word/pointer oriented. Mutual exclusion semaphores – mutexes – are independent kernel objects, which behave in a very similar way to normal binary semaphores. They are slightly more complex and incorporate the concept of temporary ownership (of the resource, access to which is being controlled). If a task obtains a mutex, only that same task can release it again – the mutex (and, hence, the resource) is temporarily owned by the task. In this section, the use of synchronization mechanisms to maintain the consistency and integrity of shared data or resources is discussed together with various approaches for intertask communication. The main concern is how to minimize time - consuming blocking that may arise in a real - time system when concurrent tasks use shared resources. Related to this concern is the issue of sharing critical resources that can only be used by one task at a time. Moreover, the potential problems of deadlock and starvation should always be kept in mind when designing and implementing resource – sharing schemes. In practice, strictly controlled mechanisms are needed that allow tasks to communicate, share resources, and synchronize their activities. Most of the mechanisms and phenomena discussed in this section are easy to understand casually, but a deep understanding may be harder to attain. Misuse of these techniques, semaphores in particular, can lead to disastrous effects — such as a deadlock. A special data structure, called a ring buffer (or circular queue), is used in the same way as a regular queue and can be used to solve the problem of synchronizing multiple reader and writer tasks. Ring buffers are easier to manage than double buffers or regular queues when there are more than two readers or writers. In the ring buffer, simultaneous input and output operations are possible by maintaining separate head and tail indices. Data are loaded at the tail and read from the head. Example: Ring Buffering Mailboxes provide an intertask communication mechanism, and are available in many commercial operating systems. A mailbox is actually a special memory location that one or more tasks can use to transfer data, or more generally for synchronization. The tasks rely on the kernel to allow them to write to the mailbox via a post operation or to read from it via a pend operation —direct access to any mailbox is not allowed. The mail that is passed via a mailbox can be a flag used to protect a critical resource (called a key), a single piece of data, or a pointer to a data structure. For example, when the key is taken from the mailbox, the mailbox is emptied. Thus, although several tasks can spend on the same mailbox, only one task can receive the key. Since the key represents access to a critical resource, simultaneous access is precluded. Mailbox queues should not be used ineffectively to pass arrays of data; pointers should be preferred in such purposes. A variety of device servers, where a pool of devices is involved, can be conveniently implemented using mailbox queues. Here, a ring buffer holds requests for a device, and mailbox
queues are used at both the head and tail to control access to the ring buffer. Such a secure scheme is useful in the construction of device – controlling software. The most common mechanism for protecting critical resources involves a binary variable called a semaphore, which is functionally similar to the traditional railway semaphore device. A semaphore is a specific memory location that acts as a lock to protect critical regions. Two system calls, wait (&s) and signal (&s), are used either to take or to release the semaphore. Risky allocation of memory is any allocation that can preclude system determinism. Such an allocation can destroy event determinism by overflowing the stack, or it can destroy temporal determinism by causing a deadlock situation. Therefore, it is truly important to avoid risky allocation of memory, while at the same time reducing the overhead incurred by memory management. In a multitasking system, the context of each task needs to be saved and
restored in order to switch tasks successfully. This can be accomplished by using one or more runtime stacks or the task control block model. Runtime stacks are adequate for interrupt - only and foreground/background systems, whereas the TCB model is more appropriate for full - featured operating
systems. If a stack is to be used to handle the runtime saving and restoring of context, two simple routines —save and restore— are needed. The save routine is called by an interrupt handler to save the current context of the system into a stack area; this call should be made immediately after interrupts have been Disabled. Moreover, the restore routine should be called just before interrupts are reenabled, and before returning from the interrupt handler. It permits tasks to interrupt themselves, thus allowing for handling transient overload conditions or for detecting spurious interrupt bursts. The real - time software can be written in a programming language that supports re-entrancy and recursion. Individual task stacks, which contain the appropriate activation records with dynamic links needed to support recursion, can be maintained for each task. A pointer to these stacks needs to be saved in the context or task control block associated with the particular task. Selecting a specific real - time operating system ( RTOS ) for a particular application is a problem for which there is no obvious solution strategy. The following are desirable characteristics for real - time systems (this discussion is adapted from Laplante [ 2005 ]:
• Fault tolerance
• Maintainability
• Predictability
• Survival under peak load
• Timeliness While the answer to that vital question depends naturally on the entire situation, commercial kernels are frequently chosen because they generally provide robust services, are easy to use, and may even be portable. Commercially available real - time operating systems are wide - ranging in features and performance, and can support many standard devices and communications network protocols. Often, these systems come equipped with helpful development and debugging tools, and they can run on a variety of hardware platforms. From business and technical perspectives, the selection of a commercial real - time operating system represents a potential make -or - break decision. It is therefore imperative that a broad and rigorous set of selection criteria be used. The following are desirable characteristics for real - time systems (this discussion is adapted from Laplante [ 2005 ]):
• Fault tolerance
• Maintainability
• Predictability
• Survival under peak load
• Timeliness Introduction:
The advent of microprocessors circa 1980 created an opportunity for new computer vendors, but they required applications software. To establish the critical mass needed to attract application suppliers required an environment that supported portability between systems. This required a common operating system (OS) interface. AT&T’s UNIX was a candidate OS portable across these diverse processors. Emerging vendors, and others building on microprocessor technology turned towards collaborative standardization to address this objective1. This vendor and processor independence was an essential objective for “Open Systems” standards. The POSIX (Portable Operating System Interface) effort focused on this as the foundation for portable applications. POISIX is credited with increasing the market for UNIX systems by 30% [18] – an economic impact approaching 100 billion dollars. 1983 – In the Beginning: AT&T's lack of strategic concern for UNIX in the early 1980's provided an opportunity for open (any interested person) standardization to be initiated and driven by others. This apparently large amount is in the same ballpark as Bill Gates
individual net worth over this time frame. Both resulted from addressing the need for operating systems for applications portability.
a)The emergence of microprocessors, most notably the
Motorola 68000, which had the capacity to host a
full UNIX implementation.
b)The release of the UNIX operating system for
commercial licensing by AT&T. The approval of the full use version of POSIX corresponded with FIPS 151, creating a solid U.S. Government alignment with the standard. The FIPS ‘selected’ from the POSIX options, reducing the viable range of variations. Harmonization activities within the WG15 group resulted in concurrent progression to draft international standard status. The model adopted at that level called for resolution of any significant international objections by means of a rapid amendment to the IEEE documents. IEEE also made arrangements to provide for the publishing of the documents (having selected an A4 page size for the IEEE version as well.)
Unit – 3
Real time operating system
Q(1) Explain the Real Time Kernels in detail.
A 1)
Real Time Kernels:
Process:
Fig.1: Hierarchical relationships between the system
Fig.2: Layers of Hardware, While Kernel Being the second Layer of it.
Q(2) Explain the Inter Task Communication & Synchronization in detail.
A 2)
Inter Task Communication & Synchronization:
shown in Figure 2.
blocks, input/output services, and other supporting features.
Q(3) Explain the Basic inter-task communication facilities provided by RTOS in detail.
A 3)
Basic inter-task communication facilities provided by RTOS:
ii. Event Flag Groups :
iii. Semaphores :
iv. Mailboxes :
v. Ques :
vi. Mutexes :
Q(4) Explain the System Services for Application Programs in detail.
A 4)
System Services for Application Programs:
Q(5) Explain the Linear Buffers , Ring Buffers, Mailboxes, Semaphores in detail.
A 5)
1. Linear Buffers:
Fig.3: Readers and writers problem, with n readers and m writers; the shared resource is a bounded buffer.
2. Ring Buffers:
Fig.4: A ring buffer; tasks write data to the buffer at the tail index and read from the head index.
3. Mailboxes
queues are used at both the head and tail to control access to the ring buffer.
4. Semaphores:
Example: Serially Reusable Resource.
Q(6) Explain the Memory Management Issues in detail.
A 6)
Memory Management Issues:
This overhead is a significant component of the context - switch time and must be minimized.
Q(7) Explain the Stack and Task Control Block Management in detail.
A 7)
Stack and Task Control Block Management:
restored in order to switch tasks successfully.
systems.
Multiple - Stack Arrangement:
Using multiple stacks in real - time systems offers clear advantages:
Fig.5: Multiple - stack arrangement
Q(8) Explain the Selecting Real-Time Operating System and Buying versus Building in detail.
A 8)
Selecting Real-Time Operating System:
• Fault tolerance
• Maintainability
• Predictability
• Survival under peak load
• Timeliness
Buying versus Building:
In short, commercial RTOSs are best used when they can satisfy the response – time requirements at a competitive cost, and if the real - time system must run on a variety of platforms.
Q(9) Explain the Selection Criteria and a Metric for Commercial Real - Time Operating Systems in detail.
A 9)
Selection Criteria and a Metric for Commercial Real - Time Operating Systems:
• Fault tolerance
• Maintainability
• Predictability
• Survival under peak load
• Timeliness
Q(10) Explain POSIX – A case study in detail.
A 10)
POSIX – A case study:
The advent of microprocessors circa 1980 created an opportunity for new computer vendors, but they required applications software. To establish the critical mass needed to attract application suppliers required an environment that supported portability between systems. This required a common operating system (OS) interface. AT&T’s UNIX was a candidate OS portable across these diverse processors. Emerging vendors, and others building on microprocessor technology turned towards collaborative standardization to address this objective1. This vendor and processor independence was an essential objective for “Open Systems” standards. The POSIX (Portable Operating System Interface) effort focused on this as the foundation for portable applications. POISIX is credited with increasing the market for UNIX systems by 30% [18] – an economic impact approaching 100 billion dollars.
A series of factors created the environment that would bring
the world’s largest and smallest computer vendors together
in the POSIX operating system standards effort:
individual net worth over this time frame. Both resulted from addressing the need for operating systems for applications portability.
a)The emergence of microprocessors, most notably the
Motorola 68000, which had the capacity to host a
full UNIX implementation.
b)The release of the UNIX operating system for
commercial licensing by AT&T.
3. 1986 – Trial use (herding cats):
The decision to create a Trial Use standard rather than full use was based on the perception that we could gain consensus faster with that approach, and also use the visibility of that work to bring in a broader community.
4. 1988 – Full Use:
This version also contained conformance clauses that defined both “system “conformance and “application” conformance.
0 matching results found