Pattern-Oriented Software Architecture, Patterns for Resource Management

By Michael Kircher and Prashant Jain

The first volume of the POSA pattern series introduced a broad-spectrum of general-purpose patterns in software design and architecture. The second narrowed the focus to fundamental patterns for building sophisticated concurrent and networked software systems and applications. This volume uses design patterns to present techniques for implementing effective resource management in a system.

The patterns are covered in detail making use of several examples providing directions to the readers on how to implement the presented patterns. Additionally, the volume presents a thorough introduction into resource management and a case study where the patterns are applied to the domain of mobile radio networks. The patterns are grouped by different areas of resource management and hence address the complete lifecycle of resources: resource acquisition, coordination and release.

• Language: English
• Publisher: Wiley
• Release date: Apr 19, 2013
• ISBN: 9781118725238

Book preview

Chapter 1

Introduction

A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools.

Douglas Adams

A resource is an entity that is available in limited supply such that there exists a requestor, the resource user, that needs the entity to perform a function, and there exists a mechanism, the resource provider, that provides the entity on request. In the context of software systems, a resource can include, among other things, memory, synchronization primitives, file handles, network connections, security tokens, database sessions, and local as well as distributed services. A resource can be anything from a heavyweight object such as an application server component [VSW02] to a fine-grained lightweight object such as a file handle.

Determining what is a resource can sometimes be challenging. For example, in programming environments an image, such as a JPEG or GIF file, is often referred to as a resource. In reality, however, there are no acquisition and release semantics defined for an image— instead, it is the data that makes up the image that constitutes a resource. Therefore a more accurate representation would be to treat the memory an image is using as a resource, which needs to be acquired when the image is loaded and released when the image is no longer needed.

There are numerous ways of categorizing resources. In the simplest, resources can be viewed as either reusable or non-reusable. Reusable resources typically are acquired from a resource provider, used and then released. Once the resources have been released they can be acquired and used again. An example of a reusable resource is memory that is allocated by and released to the operating system. Other examples of reusable resources include file handles and threads. Reusable resources are the most important form of resource, because the resource provider typically only has a limited number of resources, and therefore reusing resources that are not consumed makes logical sense. In contrast, non-reusable resources are consumed, and therefore once acquired are either not released, or their release is implicit. An example of a non-reusable resource is processing time in a computing grid [Grid04]—once the processing time is acquired and used, it is gone and cannot be returned.

A different method of categorizing resources is based on how the resources are accessed or used. A resource, once acquired, can be concurrently used either by multiple users or a single user. Examples of resources that are concurrently accessible by multiple users include services, queues, and databases. If a resource that can be concurrently accessed by multiple users has changeable state, then access to that resource needs to be synchronized. On the other hand, if a resource that can be concurrently accessed by multiple users does not have state, then no synchronization is needed. An example of a resource that does not need synchronization is a stateless session bean of a J2EE EJB [Sun04b] application server. On the other hand, a network communication socket is an example of a resource that needs synchronization. A resource that can be concurrently accessed by multiple users need not be acquired explicitly by each user. Instead, resource users can share references to the resource, such that a resource user initially acquires the resource reference and others just use it.

In contrast, if a resource can only be used by a single user, it is called an exclusive resource. An example of an exclusive resource is the processing time of a service. The processing time can be regarded as a non-reusable exclusive resource that is provided by the service, which is the resource provider. Resource users can acquire processing time from the service. The service itself can be regarded as another resource. Acquiring the service means acquiring the processing time.

Exclusive resources can be both reusable as well as non-reusable. However, if a resource is non-reusable, it is always exclusive, since it can only be used by a single resource user. Furthermore, if an exclusive resource is reusable, then it must be serially reusable—the resource is reused over time through the resource provider.

Putting resources into different categories is often neither so simple nor even meaningful. For example, in contrast to the processing time of a service, CPU time can also be regarded as an example of a valuable resource. On one hand one might regard CPU time as a non-reusable exclusive resource that is acquired by a thread, which is the resource user. However, in reality CPU time is not under the control of any application, but is instead under the control of the operating system. From an application perspective, the operating system assigns the CPU to a thread, so the thread does not really acquire the CPU as resource.

Resources often depend on other resources. For example, a file handle as a resource represents a file, which can again be thought of as a resource. Another example is a service that is provided by a component, which consists of thread and memory resources. These resource dependencies can be represented in the form of a graph across multiple layers of resource providers.

The following table summarizes the categorization of resources, giving one example per category:

1.1 Overview of Resource Management

Resource management in software systems is the process of controlling the availability of resources to resource users. A resource user can be any entity that acquires, accesses, or releases resources. Resource management includes ensuring that the resources are available when needed, that their lifecycle is deterministic and that they are released in a timely manner to ensure the liveliness of the systems that use them.

Managing resources is hard; managing them efficiently is even harder. Very often the non-functional requirements of a piece of software, such as performance, scalability, flexibility, stability, security, and quality of service, depend heavily on efficient resource management. These non-functional requirements act as forces that influence the way the software is designed and implemented. While each force can be independently addressed when developing a system, it is trying to find a balance among several of these forces that makes it especially challenging. In striking a balance among such forces, several questions and issues need to be addressed. For example, is the performance of a system more critical than making the system flexible and easy to maintain? Similarly, is predictability of the response time of a system more important than its scalability? Is fast initial access to a service more important than the average access time?

Addressing several of these forces simultaneously is challenging. This is because resolving one of the forces often requires compromising some other aspect of the system. For example, flexibility often comes at the expense of system performance. Similarly, optimizing special use cases, such as initial access to a service, usually results in an increase in complexity and very often an increase in latency in handling the average use case. A strong dependency on efficient resource management is tightly coupled with the challenge to address these often conflicting forces. Addressing most of the forces has to do with the way resources are acquired, accessed, and managed in general.

The following major forces need to be considered when designing systems with efficient resource management:

Performance. A system whose performance is critical has to exhibit many properties. Among these are low latency and high throughput. Since each action typically involves many resources, it is important to avoid unnecessary resource acquisitions, releases, and accesses that incur processing overhead and delay.

Scalability. Large and complex systems typically have a large number of resource users that access the resources multiple times. In many cases, systems are designed with use cases in mind, defining, for example the number of users to be expected. Very often these use cases are expanded over time as new requirements are added. For example, a new requirement could demand support for more users and higher transfer volumes while having minimum impact on system performance. If a system is able to fulfill these requirements it is said to be scalable. The way resources are managed and the way their lifecycle is managed plays a key role in achieving this goal. Besides the synchronization overhead, the acquisition and release of resources accounts for the largest portion of CPU cycles [SMFG01]. Besides scaling up, it is important to consider scaling down. To scale down means that software that has been designed and developed for large systems has to adapt to smaller systems and run with less resources.

Predictability. Predictability means the system behaving as it is expected to behave. In systems with real-time requirements, the maximum response time of individual operations must be predictable. To achieve predictability, a system must manage its resources with care. When optimizations are applied, they must not diminish service predictability in favor of performance or scalability.

Flexibility. A common requirement among systems is ease of configuration and customization. This implies that it should be possible to change the system configuration at the time of compilation, initialization, or run-time. Systems that are truly flexible leave this freedom to their users. In terms of resource management, therefore, the mechanics of acquisition, release and lifecycle control of resources need to be flexible, while still preserving performance, reliability, and scalability requirements.

Stability. An important requirement of software systems is that frequent resource acquisition and release should not make the system unstable. Resource allocation and management must be done in a manner that leads to efficient use of resources and avoids scenarios of resource starvation that can lead to system instability. If multiple resources interact, or are involved as a group in any action, it has to be ensured that the system does not end up in an inconsistent state due to the failure of one or more resources.

Consistency. All resource acquisition, access, and release must leave a software system in a consistent state. In particular, any inter-dependencies among resources must be well-managed to ensure system consistency.

Therefore, as can be seen, most of these forces are interdependent, and hence it is difficult to tackle one without influencing others. This is what makes resource management so hard and why it is important to address these issues in a well-structured way.

1.2 Scope of Resource Management

Resource management is an important aspect of almost every domain, ranging from small, embedded applications [NoWe00] to large enterprise systems [Fowl02], and even grid computing [BBL02]. Any system can benefit from efficient resource management regardless of the type of resources, or the availability of resources. For example, applications for small and embedded devices typically have limited resources, so the need for good resource management is obvious. The primary limiting factors are CPU performance, the available memory and the small bandwidth of networks and buses. Typical embedded applications include software for mobile phones and handheld devices.

Similarly, large enterprise systems run software for telecommunication switching and e-business applications. Such systems typically base their applications on top of frameworks and server-side component systems. In such systems, efficient resource management is essential to guarantee scalability, since adding additional hardware must be avoided to save cost.

It is common for the need for resource management to be discovered late in the development lifecycle, at the time of system integration and testing, when system analysis and performance analysis are performed. However, making changes to system design by that stage is difficult and costly. It is therefore important to address challenges in resource management early in the lifecycle of a software