Todays Lecture contents

1
Todays Lecture contents
Welcome to IS ZC 424 Software for Embedded
Systems Lecture 4 (26/02/08) Instructor in
charge Virendra S Shekhawat

• Architectural Design of Distributed Applications
• Concurrency Design Patterns and Issues

2
Configurable Architectures and s/w Components

• Concurrent message based design that is highly
  configurable
• Same s/w architecture should be capable of being
  mapped to many different system configurations
• Component based development approach
• Each sub system is a distributed self contained
  component type
• Highly configurable and message based design

3
Steps

• System Decomposition
• Sub system Decomposition
• Structure sub systems into concurrent tasks and
  information hiding objects
• System Configuration
• Once design is over, instances of it can be
  defined and configured
• The component instances of the target system are
  defined, interconnected and mapped onto a h/w
  configuration

4
System Decomposition1

• Designing Distributed Sub systems
• Use use case base collaboration diagrams
• Showing the objects which are frequently
  communicated with each other
• Gives idea for being in the same sub system
• An object can be a part of only one sub system
  although it appears in several collaboration
  diagrams
• Cohesion will decide

5
System Decomposition2

• Aggregate and Composite Sub Systems
• Objects that are part of a composite sub system
  must reside at the same location but objects in
  different locations are never in the same
  composite sub system
• Aggregate sub system is grouped by functional
  similarity, which might span over geographical
  boundaries
• Aggregate sub systems are convenient higher level
  abstraction than composite sub systems
  particularly when there are many composite sub
  systems

6
System Decomposition3

• Designing configurable sub systems
• Application specific criteria discussed in pre
  class
• Considering the distributed environments in which
  it is likely to operate
• Keeping in mind that later it has to map to
  physical nodes

7
System Decomposition4

• Distributed component configuration criteria
• In RTS a service provided by a sub system might
  be associated with a particular physical location
  or constrained to a particular hardware
• Component can satisfy more than one of the
  component configuration criteria
• Proximity of the source of the physical data
• Localized autonomy
• Performance
• Specialized hardware
• User interface
• Server

8
Designing Subsystem Interfaces1

• As component sub systems reside on different
  nodes, all communication must be restricted to
  message communication
• Loosely coupled (asynchronous)
• Send the message and does not wait for reply
• Message queue is needed
• More flexible
• May need Ack/Nack
• Ex Messages send by Elevator Subsystem i.e.
  arrived and departed (indication for the floor
  and moving direction) and elevator commitment
  (what floor it is planning to visit) message to
  Scheduler subsystem

9
Designing Subsystem Interfaces2

• Tightly coupled (synchronous)
• Sender waiting for the reply from the receiver
• Used in client/server system for RPC or remote
  method invocation
• Connection establishment is needed for several
  messages and responses
• Used only when response is needed
• Multiple Client/Server Message Communication
• Message queue is needed
• Both techniques can be used
• Application dependent? Does not affect the design
  of the server

10
Transaction Management

• Transaction
• Two or more operations performs a single logical
  function
• Either completed its entirety or not at all
• Two phase commit protocol
• Ex In Banking system transfer transaction
• Transaction design considerations
• Roll back criteria
• Partial or complete

11
Design of Server Subsystem1

• Provides service for client subsystems
• File servers, database servers etc.
• Sequential Server Subsystem
• Service client requests sequentially
• Maintains a queue for messages
• One message type for each service provided by it
• Ex. Bank transaction server
• If client demand for services is high, server can
  be a bottleneck in the system!!! ..alternate

12
Design of Server Subsystem2

• Concurrent Server Subsystem
• Several tasks can perform at a time
• Requires task scheduling
• In uniprocesser system one task is busy with I/O
  other can be running in CPU
• Problem when tasks access some common data at a
  time so needs synchronization
• Mutual exclusion algorithm and multiple readers
  and writers algorithm
• Asynchronous communication to the server

13
Distribution of Data

• Distributed server
• Data resides at several locations
• Data Replication
• Same data is duplicated in more than one location
• Process will speedup but data consistency is a
  problem
• Ex. Each instance of Elevator Subsystem maintains
  its own Local Status and Plan data abstraction
  object. Scheduler also maintains its own copy for
  each elevator.

14
System Configuration

• Issues
• More flexibility needs more configurable
  component types
• What component instances are required?
• In Elevator control system? How many floors and
  how many elevators???
• For each instance unique name is needed for
  identification
• How they should be interconnected?
• Ex Each instance of the Floor Subsystem sends a
  service request message to the Scheduler
  Subsystem. The Scheduler sends Scheduler Request
  message to individual instances of the Elevator
  subsystem, so it must identify to which elevator
  it is sending the message

15
System Configuration

• How component instances should be allocated to
  the nodes?
• Two components could be configured such that they
  can run on separate physical node. Or vice versa.

16
Example
Elevator Subsystem I node per Elevator
ltltLANgtgt
Floor Subsystem I node per floor
Schedular 1 node
17
Next

• 1. Design Patterns and Real-Time Systems
• 2. Concurrency in Real-Time Systems
• 3. Framework for Concurrency Patterns
• 4. Round Robin Pattern
• 5. Static Priority Pattern
• 6. Dynamic Priority Pattern
• 7. Conclusion

18
1. Design Patterns and Real-Time Systems

• Design Patterns.
• Generalized software solutions to commonly
  occurring problem.
• Address issues specific to domain to which they
  are applied.
• Important issues in real-time systems.
• Deadlines and performance.
• Missed deadlines may invalidate otherwise correct
  outputs.

19
2. Concurrency in Real-Time Systems

• Threads are basic units of concurrency.
• Specific concurrency issues directly related to
  thread management.
• Co-ordination (may include communication among
  threads).
• Resource Sharing.
• Scheduling.

20
2.1. Issues for Concurrency Patterns in
Real-Time Systems

• Design patterns exist for many aspects of
  concurrency in real-time systems.
• Patterns will be presented addressing specific
  issues related to concurrency in real-time
  systems.
• Fair resource allocation to threads.
• Resource protection.

21
3. Framework for Concurrency Patterns

• All patterns addressing these concerns schedule
  threads to perform series of tasks.
• Additional features added to address other
  concerns.
• General framework exists for concurrency patterns.

22
3.1 Framework Diagram for Concurrency Patterns

• Framework is separate pattern.
• Cyclic Executive Pattern.

Scheduler
Concrete Thread
23
3.2. Framework Elements for Concurrency Patterns

• Scheduler
• Initializes system, loads tasks and schedules
  them into perpetuity.
• Tasks voluntarily relinquish control when
  finished.
• Threads
• Abstract Thread Associates with scheduler.
• Concrete Thread Enforces interface compliance.

24
4. Round Robin Pattern

• More important for progress to be made than for
  deadlines to be met.
• Systems with soft deadlines.
• Employs system of fairness in scheduling
  threads.
• Tasks preempted based on time.
• Time driven, periodic systems instead of event
  driven, aperiodic systems.
• Add time based scheduling to cyclic executive
  pattern.

25
4.1. Round Robin Pattern Diagram
1

TCB
Timer
1
1
mapped
1
1
Scheduler
switchTask()
Modification from cyclic executive pattern
Concrete Thread
26
4.2. Round Robin Pattern Elements

• Thread (task) switching.
• Timer object.
• Sends ticks to scheduler to indicate when tasks
  should be switched.
• Typically configured before runtime.
• Events caught by interrupt, scheduler executes
  switchTask().
• Save thread information upon switching
• Task Control Block.
• Stores information about each thread for
  scheduler.
• Start and stop addresses.
• Stack.
• Control and data information used within each
  thread for computation.

27
5. Static Priority Pattern

• Systems where deadlines are very important.
• Hard deadlines.
• Deadline urgency (nearness) and criticality
  (importance) treated equally.
• Facilitated by priority in operating systems.
• Run thread with highest priority.
• Priorities defined at design time and do not
  change during execution.
• Modifications to round robin pattern.
• Remove time based scheduling.
• Add structures for prioritization.

28
5.1. Static Priority Pattern Characteristics

• Popular concurrency pattern.
• Represents common situation in real-time systems.
• Simple to analyze for schedulability.
• Rate Monotonic Scheduling (RMS).
• Shorter period tasks have higher priority.
• Periodic, interruptible tasks.
• Deadline Monotonic Scheduling (DMS).
• Deadlines not necessarily at end of period.
• Priorities set on length of deadline.

29
5.2 Static Priority Pattern Diagram
Modification from round robin pattern
1
TCB

1
mapped
1
Scheduler
createThread(addr,priority) destroyThread(TCBaddr)
blockThread(mutexID,addr) unblockThread(mutexID)
return(TCBaddr)

Concrete Thread
30
5.3 Static Priority Pattern Elements

• Queues
• References to TCBs for threads
• Ordered by priority
• Ready Queue
• Holds references to threads ready to execute.
• Blocked Queue
• Holds references to threads blocked until a
  required resource is available.
• Shared Resources
• Object shared and required by one or more
  threads.
• Must be protected against corruption through
  simultaneous access.
• Each resource protected by a mutual exclusion
  (mutex) semaphore.

31
6. Dynamic Priority Pattern

• Some systems require emphasis of urgency over
  criticality in deadlines.
• However, operating systems only provide priority
  to deal with both issues.
• Therefore, it is necessary to change the priority
  of threads during runtime to emphasize urgency.

32
6.1. Dynamic Priority Pattern Characteristics

• Scheduling policy has greater significance
• Strategy must be explicitly developed to change
  priority.
• Most common is Earliest Deadline First (EDF).
• Thread with closest deadline always takes highest
  priority.
• Priorities changes as threads execute.
• Urgency becomes most important factor in thread
  execution.
• Minor changes to static priority pattern.

33
6.2. Dynamic Priority Pattern Diagram
Modification from static priority pattern
1
TCB

Ready Queue Priority Queue
1
1
mapped
1
1
Scheduler
createThread(addr,priority) destroyThread(TCBaddr)
blockThread(mutexID,addr) unblockThread(mutexID)
return(TCBaddr)

Concrete Thread
Modification from static priority pattern
34
6.3. Dynamic Priority Pattern Elements

• New Attributes from Static Priority Pattern
• Deadline (AbstractThread).
• Length of time after thread invocation where
  thread must be complete.
• AbsoluteDeadline (Task Control Block).
• Next deadline for a given thread.
• Calculated with AbstractThread Deadline.
• Used to determine threads current priority.

35
7. Conclusion

• Design Patterns present predefined solutions for
  software systems.
• Patterns for real-time concurrency emphasize
  thread scheduling and resource sharing.
• Round robin pattern used for systems with soft
  deadlines and fair scheduling.
• Static priority pattern for systems with hard
  deadlines with equal emphasis on urgency and
  criticality.
• Dynamic priority pattern for systems emphasizing
  deadline urgency over criticality.

36
Outline

• Concurrency Problems
• Mutual Exclusion Problem
• Message Queuing Pattern
• Guarded Call Pattern
• Rendezvous Pattern
• Conclusions
• References

37
Concurrency Problems

• The threads are usually not really independent
• They must coordinate, synchronize, and share
  information
• Scheduling characteristics of the concurrent
  threads
• Synchronizing threads when they are required to
  share data or control information
• Management of shared resources that must be
  protected from simultaneous access
• The concurrency patterns provide some solutions
  to these commonly occurring problems

38
Mutual Exclusion Problem

• Interleaved writing of the values
• Getting an incorrect value from a shared resource
  because it read partway through an update from
  another task
• Shared resources must be protected from mutual
  exclusion problems

39
Message Queuing Pattern

• In most multithreaded systems, threads must
  synchronize and share information with others
• synchronizing to permit sharing of the
  information
• protecting shared information
• The message queuing pattern uses asynchronous
  communications, implemented via queued messages,
  to synchronize and share information among tasks.
• No mutual exclusion problems

40
Message Queuing Pattern Structure
41
Pros and Cons

• Simplicity
• Supported by all real-time operating system
• Heavy weight

42
Guarded Call Pattern

• A problem of the Message Queuing Pattern it does
  not provide timely responses
• An alternative is to synchronously invoke a
  method of an object
• To avoid mutual exclusion problem
• The Guarded Call Pattern solves these problems by
  guarding the access to the resource via the
  synchronous operation called across the thread
  boundary with a semaphore

43
Guarded Call Pattern Structure
44
Sample model
45
Pros and Cons

• Providing a timely response
• Protect from corruption due to mutual exclusion
  problems
• If the resource is protected, then timely
  response cannot be guaranteed unless the service
  is schedulable

46
Rendezvous Pattern

• Message Queuing Pattern and Guarded call pattern
  cannot handle threads synchronization with
  complex synchronization policies
• Rendezvous pattern is to codify a collaboration
  structure that allows any arbitrary set of
  preconditional invariants (synchronization
  policy) to be met for thread synchronization,
  independent of task phases, scheduling policies,
  and priorities.
• synchronizing a set of threads
• or permitting data sharing among a set of threads

47
Rendezvous Pattern structure
48
Sample model
49
Conclusions

• Message Queuing Pattern provides a simple means
  for threads to asynchronously communicate
  information via queues
• Guard Call Pattern is a synchronous rendezvous,
  providing a timely response or data exchange
  between threads
• Rendezvous Pattern provides a great deal of
  flexibility in synchronizing a set of threads
  With complex synchronization policies