Topics of discussion
 Real-time embedded systems
 A computer system in which correctness of the system behavior
depends not only on the logical results of the computation, but also
the instant at which results are computed and produced.
 Hard real-time
 Systems where failing to meet time constraints are unacceptable
 Potential catastrophic consequences
 Examples: brake-by-wire system, fly-by-wire aircraft navigation control,
safety critical systems
1
 Soft real-time
 Systems where under certain circumstances, some amount of delay
is acceptable but not desirable
 Occasional missed deadline or aborted execution is typically
tolerated, small average response time may be more important to the
system
 Timing requirements can be specified in probabilistic terms i.e. 1
missed deadline per hour
2
 Release time
 This is the instant of time at when the job becomes available for
execution
 The job can be scheduled by the processor and execute any time
after its release time if its data and control dependencies are met
 Deadline
 The time when the job execution is required to be completed
 Response Time
 Time from the release of a job till its completion
3
 Heterogeneous distributed systems, heterogeneous processing nodes
 Several different networks interconnected with each other
 Two such networks are connected and communicate via a gateway
 Each function may not be running on a dedicated processing node
4
 Middleware software
 Used to abstract software functions from hardware difference of
the processing nodes in a heterogeneous embedded system
 Applications distributed across networks
 Applications distributed on the same network
 Or even on the same processing node
5
 Analysis and synthesis of real-time embedded and safety-critical
distributed applications
 Architecture selection
 Hardware platform selection and platform based design
 Software function specification
 Using control and dataflow graphs
 Task mapping and schedule mapping
 Inter-node and inter-process communications
 Universal Modeling Language (UML) used for Object Oriented
Analysis & Design (OOA) (OOD)
6
 The design tasks have to be performed such that the timing constraints
of hard real-time applications are satisfied and implementation costs are
minimized
 Design of real-time systems or any software system very seldom
starts from scratch
 System products typically start from an already existing system/
product
 Software reuse based on middleware software and common
hardware platform design
 All systems must be structured such that additional functionality can
easily be added and accommodated in the future
 Incremental design process
 Spiral design, integration and test model
7
 Time-driven systems
 Activation of processes and transmission of messages happen at
predetermined points in time
 Communication protocols used:
 Time division Multiple Access (TDMA)
 Controller Area Network (CAN) Protocol
 Non-preemptive static scheduling approach for both processes
and messages
 Time Triggered Protocol (TTP)
8
 Event-driven systems
 Activation of processes are done at the occurrence of significant
events
 Multi-cluster systems
 Combines time-driven and event-driven systems into heterogeneous
network
9
 Concurrent Processes
 Two processes are concurrent if their execution can overlap in time
 In multi-processor systems, concurrent processes can use different CPUs at
the same time
 In single processing systems, concurrent processing can be thought of as
one process using the CPU while another process uses system I/O, etc.
 If a CPU interleaves the execution of several processes, logical
concurrency is obtained
 Processes are serial if the execution of one must be complete before the
execution of the other can start
 Concurrent processes interact using the following mechanisms:
 Shared variables
 Message passing
10
 Threads
 Threads are mini processes within a process and therefore share the
address space with the processes
 Every process has at least one thread
 A thread executes a portion of the program and cooperates with other
threads concurrently executing within the same process and address
space
 Because threads share the same address space, it is more efficient to
perform a context switch between two threads of the same process
than it is to perform a context switch between two separate processes
 Each thread has its own program counter and control block
11
 Critical Sections
 In multiprocessing systems, processes or threads may compete with
each other for system resources that can only be used exclusively
 CPU is a good example of this type of resource as only one process or thread
can execute instructions on a single CPU at a time
 Processes may also cooperate with each other by using shared
memory or message passing
 For both of these cases, mutual exclusion is necessary to insure that
only one process or thread at one time holds a resource or modify
shared memory
 A critical section is a code segment in a process in which some shared
resource is accessed
12
 A solution to the mutual exclusion problem must satisfy the following
requirements:
 Only one process can execute its critical section at any one time
 When no process is executing in its critical section, any process that requests
entry to its critical section must be permitted to enter without delay
 When two or more processes compete to enter their respective critical sections,
the selection cannot be postponed indefinitely (Deadlock)
 No process can prevent any other process from entering its critical section
indefinitely (Starvation)
13
 Some Mechanisms for Insuring Mutual Exclusion
 Polling or Busy waiting
 Disabling interrupts
 Semaphores
14
 Semaphores
 A semaphore is an integer variable S and an associated group of
waiting processes for which only two operations may be performed:
Wait state P(S): if S  1 then S := S – 1
else the executing process waiting for the semaphore S joins the wait queue for S and
forfeits the resource;
endif
Signal state V(S): if wait queue for S is not empty then remove a process from the queue
and give it the resource
else S := S + 1
endif
15
 A semaphore can be used for synchronization and mutual exclusion
 Synchronization: Coordination of various tasks or processes
 Mutual exclusion: Protection of one or more resources or implementation of
critical sections among several competing processes sharing the critical
section
 There are three types of semaphores:
 Binary semaphores
 Mutual exclusion semaphores (mutex)
 Counting semaphores
16
 Binary Semaphores
 Simplest form of the semaphore
 Primarily used for synchronization

Can also be used for mutual exclusion
 Using a binary semaphore, a process can wait (block or pend) on an event
which triggers the release of a semaphore
 Should be used in place of polling
- Polling is an inefficient way of synchronization or event waiting because of the use of processor
resources
- Using semaphores, the process is in a blocked or pended state while other processes use the
processor
- Upon the occurrence of the event, the pended process becomes ready to execute
17
 Mutual Exclusion Semaphores
 Used to provide resource consistency in a system for resources shared
simultaneously by multiple tasks
- Shared resources can be such as shared data, files, hardware, devices, etc.
 To protect against inconsistency in a multi-tasking system, each task must
obtain exclusive access right to a shared resource
18
 One common problem that can occur without designing proper mutual
exclusion in a multi-tasking system sharing resources simultaneously is
known as the “Racing condition”
- Based on which task gets to the resource first the system behavior is different
- Racing conditions can go on undetected for a very long time in a system and can be a very
difficult problem to detect and fix
 When using mutual exclusion semaphores, be aware of the racing
condition; deadlock
- Use only one mutual exclusion semaphore to protect resources that are used together
 When using mutual exclusion semaphores, avoid starvation situations
- Do not include unnecessary sections in the critical section
 Mutual exclusion semaphores can not be used in interrupt service routines
19
 Counting Semaphores
 Another mean to implement task synchronization and mutual exclusion
 Counting semaphore is just like the binary semaphore with the exception
that it keeps track of the number of times a semaphore has been given or
taken
- Counting semaphores use a counter to keep track of the semaphores and hence the name,
counting semaphore!
- The semaphore is created with a fixed number of semaphores available
- Every time that a semaphore is taken, the semaphores count is decremented
- When a semaphore is given back, if a task is blocked on the semaphore, it takes the semaphore;
otherwise, the semaphores count is incremented
 Counting semaphores are generally used to guard resources with multiple
instances
20
Classical Synchronization Problems
 The dining philosophers problem
 The producer-consumer problem
 The readers-writes problem
 Reader’s priority
 Writer’s priority
21