Concurrency Viewpoint

Historically, information systems were designed to operate with little or no concurrency, running via batch mode on large central computers. A number of factors (including distributed systems, increasing workloads, and cheap multiprocessor hardware) have combined so that today's information systems often have little or no batch mode operations.

In contrast, control systems have always been inherently concurrent and event-driven, given their need to react to external events in order to perform control operations. It is natural, then, that as information systems become more concurrent and event-driven, they start to take on a number of characteristics traditionally associated with control systems. Similarly, it is unsurprising that, in order to deal with this concurrency, the information systems community has adopted and adapted proven techniques from the control systems community. Many of these techniques form the basis of the Concurrency viewpoint.

The Concurrency view is used to describe the system's concurrency and state-related structure and constraints. This involves defining the parts of the system that can run at the same time and how this is controlled (e.g., defining how the system's functional elements are packaged into operating system processes and how the processes coordinate their execution). To do this, you need to create a process model and a state model: The process model shows the planned process, thread, and interprocess communication structure; the state model describes the set of states that runtime elements can be in and the valid transitions between those states.

Once you have created concurrency and state models, you can use a number of analysis techniques to ensure that the planned concurrency scheme is sound. The use of such techniques is typically part of creating a Concurrency view, too.

It's worth noting that not all information-based systems really benefit from a Concurrency view. Some information systems have little concurrency. Others, while exhibiting concurrent behavior, use the facilities of underlying software packages (e.g., databases) to hide the concurrency model actually in use.

Definition	Describes the concurrency structure of the system, mapping functional elements to concurrency units to clearly identify the parts of the system that can execute concurrently, and shows how this is coordinated and controlled
Concerns	- task structure - mapping of functional elements to tasks - interprocess communication - state management - synchronization and integrity - startup and shutdown - task failure - reentrancy
Models	- system-level concurrency models - state models
Pitfalls	- modeling the wrong concurrency - excessive complexity - resource contention - deadlock - race conditions
Stakeholders	Developers, testers, and some administrators
Applicability	All information systems with a number of concurrent threads of execution

find out more about the Concurrency viewpoint ...