UNIT-3

Real time operating system

3.1 Real Time Kernels

1. Process:

•  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.

Key Takeaways:

1. 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.
2. 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.

3.2 Inter Task Communication & Synchronization

• 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:

1. 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.
2. 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.
3. 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”.

3.2.1 Basic inter-task communication facilities provided by RTOS:

1. 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.

ii.            Event Flag Groups :

• 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.

iii.            Semaphores  :

• 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.

iv.            Mailboxes  :

• 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.

v.            Queues :

• Queues 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.

vi.            Mutexes :

• 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.

Key Takeaways:

1. 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.
2. A kernel also provides for intertask communication and synchronization via mailboxes, queues, pipes, and semaphores.

3.3 System Services for Application Programs

• 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.

3.3.1 Linear Buffers:

3.3.2 Ring Buffers:

• 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

3.3.3 Mailboxes

• 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.

3.3.4 Semaphores:

• 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.
• Example: Serially Reusable Resource.

Key Takeaways:

1. The main concern is how to minimize time - consuming blocking that may arise in a real - time system when concurrent tasks use shared resources.
2. Misuse of these techniques, semaphores in particular, can lead to disastrous effects — such as a deadlock.
3. Mailboxes provide an intertask communication mechanism, and are available in many commercial operating systems.
4. 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.
5. 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.

3.4 Memory Management Issues:

• 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.
• This overhead is a significant component of the context - switch time and must be minimized.

3.4.1 Stack and Task Control Block 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.

3.4.2 Multiple - Stack Arrangement:

Using multiple stacks in real - time systems offers clear advantages:

• 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.

Key takeaways:

1. Risky allocation of memory is any allocation that can preclude system determinism.
2. Such an allocation can destroy event determinism by overflowing the stack, or it can destroy temporal determinism by causing a deadlock situation.
3. Therefore, it is truly important to avoid risky allocation of memory, while at the same time reducing the overhead incurred by memory management.

3.5 Selecting Real-Time Operating System

• 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

3.5.1 Buying versus Building:

• 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.
•  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.

3.5.2 Selection Criteria and a Metric for Commercial
Real - Time Operating Systems:

• 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

Key takeaways:

1. Selecting a specific real - time operating system ( RTOS ) for a particular application is a problem for which there is no obvious solution strategy.
2. 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

POSIX – A case study:

1. 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.

2.     1983 – In the Beginning:

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:

1. 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.
2. 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.

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:

• 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.)
• This version also contained conformance clauses that defined both “system “conformance and “application” conformance.
   

Key Takeaways:

1. The POSIX (Portable Operating System Interface) effort focused on this as the foundation for portable applications.
2. POSIX is credited with increasing the market for UNIX systems by 30% [18] – an economic impact approaching 100 billion dollars.

Reference:

1. Real- Time Systems Design and Analysis.. Tools for the Practitioner by Phillip A    Laplante
2. Embedded Real Time Systems: Concepts, Design and Programming – Dr. K.V.K. Prasad - Black Book, Edition: 2014

UNIT-3

Real time operating system

3.1 Real Time Kernels

1. Process:

•  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.

Key Takeaways:

1. 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.
2. 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.

3.2 Inter Task Communication & Synchronization

• 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:

1. 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.
2. 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.
3. 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”.

3.2.1 Basic inter-task communication facilities provided by RTOS:

1. 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.

ii.            Event Flag Groups :

• 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.

iii.            Semaphores  :

• 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.

iv.            Mailboxes  :

• 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.

v.            Queues :

• Queues 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.

vi.            Mutexes :

• 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.

Key Takeaways:

1. 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.
2. A kernel also provides for intertask communication and synchronization via mailboxes, queues, pipes, and semaphores.

UNIT-3

Real time operating system

3.1 Real Time Kernels

1. Process:

•  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.

Key Takeaways:

1. 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.
2. 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.

3.2 Inter Task Communication & Synchronization

• 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:

1. 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.
2. 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.
3. 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”.

3.2.1 Basic inter-task communication facilities provided by RTOS:

1. 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.

ii.            Event Flag Groups :

• 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.

iii.            Semaphores  :

• 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.

iv.            Mailboxes  :

• 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.

v.            Queues :

• Queues 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.

vi.            Mutexes :

• 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.

Key Takeaways:

1. 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.
2. A kernel also provides for intertask communication and synchronization via mailboxes, queues, pipes, and semaphores.

3.3 System Services for Application Programs

• 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.

3.3.1 Linear Buffers:

3.3.2 Ring Buffers:

• 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

3.3.3 Mailboxes

• 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.

3.3.4 Semaphores:

• 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.
• Example: Serially Reusable Resource.

Key Takeaways:

1. The main concern is how to minimize time - consuming blocking that may arise in a real - time system when concurrent tasks use shared resources.
2. Misuse of these techniques, semaphores in particular, can lead to disastrous effects — such as a deadlock.
3. Mailboxes provide an intertask communication mechanism, and are available in many commercial operating systems.
4. 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.
5. 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.

3.4 Memory Management Issues:

• 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.
• This overhead is a significant component of the context - switch time and must be minimized.

3.4.1 Stack and Task Control Block 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.

3.4.2 Multiple - Stack Arrangement:

Using multiple stacks in real - time systems offers clear advantages:

• 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.

Key takeaways:

1. Risky allocation of memory is any allocation that can preclude system determinism.
2. Such an allocation can destroy event determinism by overflowing the stack, or it can destroy temporal determinism by causing a deadlock situation.
3. Therefore, it is truly important to avoid risky allocation of memory, while at the same time reducing the overhead incurred by memory management.

3.5 Selecting Real-Time Operating System

• 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

3.5.1 Buying versus Building:

• 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.
•  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.

3.5.2 Selection Criteria and a Metric for Commercial
Real - Time Operating Systems:

• 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

Key takeaways:

1. Selecting a specific real - time operating system ( RTOS ) for a particular application is a problem for which there is no obvious solution strategy.
2. 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

POSIX – A case study:

1. 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.

2.     1983 – In the Beginning:

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:

1. 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.
2. 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.

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:

• 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.)
• This version also contained conformance clauses that defined both “system “conformance and “application” conformance.
   

Key Takeaways:

1. The POSIX (Portable Operating System Interface) effort focused on this as the foundation for portable applications.
2. POSIX is credited with increasing the market for UNIX systems by 30% [18] – an economic impact approaching 100 billion dollars.

Reference:

1. Real- Time Systems Design and Analysis.. Tools for the Practitioner by Phillip A    Laplante
2. Embedded Real Time Systems: Concepts, Design and Programming – Dr. K.V.K. Prasad - Black Book, Edition: 2014