List-Update Containers

This section describes list-based containers. It is organized as follows.

  1. Overview is an overview.
  2. List Updates describes updating lists as elements are accessed.

Overview

Associative containers typically use some attributes of the keys of which they store: tree-based containers use the ability to compare keys; hash-based containers use the ability to map keys into numbers.

In some cases it is better to avoid this:

  1. Hash-based and tree-based containers typically require additional memory for time efficiency.
  2. Hash-based and tree-based containers require extra information about keys: hash-based containers need hash functors, tree-based containers need comparison functors. In some (rare) cases, a key might be encapsulated to the extent that it is not possible to supply these functors.

In such cases, storing the entries in a unique-key list is a reasonable solution. This uses the minimal amount of memory, and requires only an equivalence functor. Clearly, the order of the elements within the list affects performance; ideally, frequently accessed elements should be at the front of the list.

Many remarkable (online competitive [motwani95random]) algorithms exist for reordering lists to reflect access prediction [andrew04mtf].

Figure List-update containers shows the container-hierarchy; the list-based container is circled.

no image
List-update containers.

The list-based container has the following declaration:

template<
	typename Key,
	typename Data,
	class Eq_Fn = std::equal_to<Key>,
	class Update_Policy =
		move_to_front_lu_policy<>,
	class Allocator =
		std::allocator<char> >
class lu_assoc_cntnr;

The parameters have the following meaning:

  1. Key is the key type.
  2. Data is the data-policy, and is explained in Mapping-Semantics Genericity::Data Types as a Policy.
  3. Eq_Fn is a key equivalence functor.
  4. Update_Policy is a policy updating positions in the list based on access patterns. It is described in the following subsection.
  5. Allocator is (surprisingly) an allocator type.

List Updates

This subsection describes list-update policies. It is organized as follows.

  1. General Terms describes general terms.
  2. Implementation in pb_assoc describes the implementation of these concepts in pb_assoc.

General Terms

For example, Figure -A The counter algorithm shows the counter algorithm. Each node contains both a key and a count metadata (shown in bold). When an element is accessed (e.g. 6) its count is incremented, as shown in Figure The counter algorithm -B. If the count reaches some predetermined value, say 10, as shown in Figure The counter algorithm -C, the count is set to 0 and the node is moved to the front of the list, as in Figure The counter algorithm -D.

The counter algorithm.

Implementation in pb_assoc

The pb_assoc library allows instantiating lists with policies implementing any algorithm moving nodes to the front of the list (policies implementing algorithms interchanging nodes are currently unsupported).

Associative containers based on lists are parameterized by a Update_Policy parameter. This parameter defines the type of metadata each node contains, how to create the metadata, and how to decide, using this metadata, whether to move a node to the front of the list. A list-based associative container object derives (publicly) from its update policy.

An instantiation of Update_Policy must define internally update_metadata as the metadata it requires. Internally, each node of the list contains, besides the usual key and data, an instance of typename Update_Policy::update_metadata.

An instantiation of Update_Policy must define internally two operators:

update_metadata
  operator()
  ();

bool
  operator()
  (update_metadata &);

The first is called by the container object, when creating a new node, to create the node's metadata. The second is called by the container object, when a node is accessed (e.g., when a find operation's key is equivalent to the key of the node), to determine whether to move the node to the front of the list.

Additionally, the library contains implementations of the move-to-front and counter policies. These are described in Policy Classes.