Part III: Contents Of The Process Handbook
10.6 A Generic Model of Resource Flows
10.6.5 Putting It All Together — Flow Dependencies
The design dimensions of generalized resource dependencies are the sum of the design dimensions of their component dependencies (figure 10.17). For each combination of
dimension values, a different special case of resource flow can be defined. The following is a discussion of the different dimensions and the alternative flow dependencies they can be used to define.
Figure 10.17: First two levels of design dimensions for flow dependencies
Resource Kind The most important design dimension is the kind of resource. Section 10.7 will describe how resource dependencies are specialized according to this dimension.
Prerequisite Relationship Another important dimension is the kind of prerequisite requirement. According to this dimension, resource relationships are classified as follows:
Persistent flows. In these situations one or more resources are produced once, and can then be used an infinite amount of times. In software systems, they arise often to
describe the use of calculated constants, and system resources (printers, network channels, etc.) that are set up once and then used an indefinite amount of times.
Perishable flows. This more refined special case of permanent dependencies describes situations where produced resources can be used an indefinite amount of times until they become invalidated. File caching provides an example application where this type of flow describes the underlying interdependency. Cached file blocks are transferred (produced) once from disk and can then be read an arbitrary number of times until some other process modifies their corresponding disk block. Then the cached file blocks become invalidated and have to be refreshed from disk before they can be read again.
Cumulative flows. In these situations every resource produced can only be used once.
Producers and users can proceed asynchronously, but at no time can the number of user accesses exceed the number of produced resources. Reading and writing a pipe channel by two separate processes is an example of this type of flow.
Transient flows. In these situations a stream of resources is produced, but the use of each resource is optional. Thus new resources in the stream can overwrite previous ones, possibly before they have been used. One example application where transient flows describe the underlying interdependency is a log file that is periodically being updated and can be printed by a user at will. Not all versions of the file need to be printed. Therefore new updates can overwrite the previous contents of the file without the need for additional coordination.
Lockstep flows. These situations occur where there must exist tight synchronization between producers and users of resources. All resources produced must be used and no resource can be produced until all previous resources have been used by all designated users. Stream data flows using nonbuffered (indivisible) carriers are examples of lockstep flows.
MANAGING PREREQUISITE COORDINATION PROCESSES The coordination process selected to manage a prerequisite dependency at the heart of a resource flow has a profound influence on the overall organization of the interacting activities.
Corresponding to the four generic classes of prerequisite coordination processes, we have an equivalent taxonomy of flow organizations:
Producer push. In push organizations, also called eager flows, resource users explicitly receive control from producers every time a new resource has been produced. Only lockstep flows can be implemented in this manner.
If control is transferred to users using synchronous calls, this organization reduces to what is commonly called client/server architecture. The resource producers act as clients and resource users act as servers.
Consumer pull. In pull organizations, also called lazy flows, resource producers are invoked by users whenever the latter require a new resource. Only lockstep and permanent flows can be implemented in this manner.
Pull organizations of flow dependencies also reduce to client/server architectures.
Resource users act as the clients and resource producers act as the servers. Note, however, that the direction of the client/server relationship is the inverse of the direction of the flow relationship.
Peer synchronization. In peer organizations producers and users are executed by separate threads of control and synchronize themselves through events. This is a more loose organization, appropriate for managing all kinds of flows. It is particularly suitable for organizing cumulative and transient flows. It might not be as effcient for managing lockstep flows, where tight synchronization is required. Examples of flow processes that are organized in this manner include pipe channel flows, shared memory flows with separate semaphore synchronization, tuple space flows, and so on. Ada's rendezvous interprocess communication paradigm (DoD 1983) is one well-known specialization of peer organizations. Other researchers have used the term implicit invocation
architectures to characterize such organizations (Garlan 1988).
Controlled hierarchy. Such organizations typically result in systems with centralized control, where a main program explicitly controls the sequence of flow participants.
Number of Producers and Users—Sharing Dimensions
One-to-one dependencies. These are the simplest kinds of dependencies. The defining dimensions are the kind of resource and the kind of prerequisite relationship. There are no sharing considerations.
One-to-many dependencies. In one-to-many dependencies, resource sharing becomes an issue. Different dependency types can be defined for each combination of resource sharing dimensions of each of the users. Some interesting special cases are:
One-to-all dependencies. Each resource flows to all users
One-to-one-of-many dependencies. Each resource flows to one of the users. This can be managed in an application-independent way (e.g., first come–first served), or in an application-specific way. In the latter case, user consumer ports usually provide additional pieces of information, such as user priorities.
Many-to-one dependencies. In many-to-one dependencies, user sharing issues have to be addressed. Users might not be willing to receive all resources produced, or they might not be able to receive them concurrently.
Situations where users are not willing to receive all resources produced are often
referred to as race conditions. In our framework, race conditions are modeled as many- to-one dependencies where the user activity acts as a consumable ''resource.''General ways of managing consumable resources can be used to manage the dependency.
Many-to-many dependencies. These dependencies are the most complex family because they can specialized according to both resource-and user-sharing dimensions.
Some interesting special cases include:
Each-to-all. Every resource produced flows to all users Each-to-one. Every resource produced flows to one user only Each-from-one. Each user receives one resource only
All-from-one. Only one of the resources produced flows to (all) users
The design alternatives for managing resource dependencies are the product of the different alternatives for managing each component dependency. In principle, each of the component dependencies can be managed by independent coordination processes. In practice,
however, there often exist opportunities to increase effciency by managing patterns of dependencies using joint coordination processes. This gives rise to additional design
alternatives that designers should be aware of. We have already encountered the opportunity to use joint coordination processes for managing accessibility and sharing (restrict resource transportation, replicate resource). In the following sections we will encounter more
opportunities for joint dependency management.