Topics

Concurrency Approaches To top of page

The concurrency requirements of the system can have a dramatic impact upon the architecture of the system. The decision to move functionality from a uni-process architecture to a multi-process architecture introduces significant changes to the structure of the system, in many dimensions. Additional mechanisms (e.g. remote procedure calls) may need to be introduced which may substantially change the architecture of the system.

System availability requirements must be considered, as well as the additional overhead of managing the additional processes and threads.

As with most architectural decisions, changing the process architecture effectively trades one set of problems for another:

Approach

Advantages

Disadvantages
Uni-process, no threads
  • Simplicity
  • Fast intra-process messaging
  • Hard to balance workload
  • Swapping and context switches are expensive
  • Can’t scale to multiple processors
Uni-process, multi-threaded
  • Fast intra-process messages
  • Multi-tasking without inter-process communication
  • Better multi-tasking without the overhead of 'heavyweight' processes
  • Application must be 'thread-safe'
  • Operating system must have efficient thread-management
  • Shared memory issues need to be considered
Multi-process
  • Scales well as processors are added
  • Relatively easy to distribute across nodes
  • Sensitive to process boundary: using inter-process communication too much hurts performance
  • Harder to design

A typical evolutionary path is to start with a uni-process architecture, adding processes for groups of behaviors that need to occur simultaneously. Within these broader groupings, consider additional needs for concurrency, adding threads within processes to increase concurrency.

Issues To top of page

Unfortunately, like many architectural decisions, there are no easy answers; the right solution involves a carefully balanced approach. Small architectural prototypes can be used to explore the implications of a particular set of choices.  In prototyping the process architecture, focus on scaling the number of processes up to the theoretical maximums for the system. Consider the following issues:

  • Can the number of processes be scaled up to the maximum?  How far beyond the maximum can the system be pushed?  Is there allowance for potential growth?
  • What is the impact of changing some of the processes to lightweight threads which operate in a shared process address space?
  • What happens to response time as the number of processes are added? As the amount of inter-process communication (IPC) is increased? Is there noticeable degradation?
  • Could the amount of IPC be reduced by combining or reorganizing processes? Would such a change result in large monolithic processes which are difficult to load-balance?
  • Can shared memory be used to reduce IPC?
  • Should all processes get "equal time" when time resources are allocated? Is it possible to carry the time allocation? Are there potential draw-backs to changing the scheduling priorities?
 

Display Rational Unified Process using frames

 

© Rational Software Corporation 1998 Rational Unified Process 5.1 (build 43)