.. sources: `_ .. index:: single: location dependency single: dependency; location .. _topic-location: Location dependency =================== Location dependencies provide a means by which the :term:`client program` can depend on the :dfn:`location` of blocks (that is, on the bits in pointers to the blocks) in the presence of a :term:`moving memory manager` (where the location of blocks may change and the client program needs to recognize and correctly deal with such cases). The interface is intended to support (amongst other things) address-based hash tables and that will be used as a running example. See the section :ref:`guide-advanced-location` in the Guide for a more detailed look at this example. Terminology ----------- A :dfn:`location dependency` is represented by an structure of type :c:type:`mps_ld_s`. It encapsulates a set of dependencies on the locations of blocks. It can be used to determine whether any of the blocks have been moved by the memory manager. To :dfn:`depend` on the location of a block is to perform a computation whose result depends on the particular representation (that is, the "bit-pattern") of a reference to the block. This includes any sort of hash operation on a pointer to the block (such as treating the pointer as an integer and taking it modulo 257). It is possible to depend on the location of more than one block. A dependency has been made :dfn:`stale` if the block whose location was depended on might have moved since the dependency was made. If this is the case, then computations that depend on the location of a block may give different results. A location dependency has been made stale if any of the blocks whose location has been depended on might have moved since the respective dependency was made. .. index:: single: location dependency; creating Creating dependencies --------------------- The :term:`client program` must provide space for the :c:type:`mps_ld_s` structure. Typically, this will be inlined in some larger structure. This structure can be in memory managed by the MPS or elsewhere; that doesn't matter. For example, the toy Scheme interpreter inlines the location dependency in its hash table structure: .. code-block:: c :emphasize-lines: 5 typedef struct table_s { type_t type; /* TYPE_TABLE */ hash_t hash; /* hash function */ cmp_t cmp; /* comparison function */ mps_ld_s ld; /* location dependency */ obj_t buckets; /* hash buckets */ } table_s; Before the first use, the location dependency must be reset by calling the function :c:func:`mps_ld_reset`. .. note:: It is not possible to statically create a location dependency that has been reset. You can call :c:func:`mps_ld_reset` at any later point to clear all dependencies from the structure. For example, this is normally done whenever :c:func:`mps_ld_isstale` returns true. .. index:: single: location dependency; adding Adding dependencies ------------------- *Before* the location of a block is depended on (for example, hashed) a reference to the block may be added to a location dependency by calling :c:func:`mps_ld_add`. Dependencies on many blocks can be added to the same location dependency. It is also possible to merge two location dependencies by calling :c:func:`mps_ld_merge`, which has the same effect as adding all of the references from one dependency to another. For example, in an address-based hash table implementation, each key that is added to the table must be added to the dependency before its address is hashed. In the toy Scheme interpreter this is most easily done in the function that hashes an address: .. code-block:: c :emphasize-lines: 4 static unsigned long eq_hash(obj_t obj, mps_ld_t ld) { union {char s[sizeof(obj_t)]; obj_t addr;} u; if (ld) mps_ld_add(ld, arena, obj); u.addr = obj; return hash(u.s, sizeof(obj_t)); } .. index:: single: location dependency; testing staleness single: staleness; testing Testing dependencies for staleness ---------------------------------- When the location of a block is used, first carry out the computation in the normal way. For example, when looking up a key in an address-based hash table, start by hashing the pointer and looking up the corresponding index in the table. If this succeeds (for example, the key was found in the table at the place indicated by the hash of its address), then no further test is required: the operation can proceed as usual. But if the operation fails, you might be in one of two cases: #. the location of the block has not been depended on before (for example, the key has never been added to the hash table); #. the location of the block has been depended on before (for example, the key was added to the hash table), but the block has moved and the dependency has become stale. At this point you should call :c:func:`mps_ld_isstale`. If it returns false, then you know that the block has not moved, so you must be in case (1). But if :c:func:`mps_ld_isstale` returns true, you could still be in either case (1) or case (2). All :c:func:`mps_ld_isstale` tells you is that the block *might* have moved, not whether the block *has* moved. At this point you must: #. reset the location dependency; #. repeat the computation in some way that doesn't depend on the old locations of all the blocks that were added to that dependency; and #. re-add a dependency on each block. For example, in the case of a hash table you should rehash based on the new locations of the blocks. In the toy Scheme interpreter this behaviour is encapsulated into ``table_find``: .. code-block:: c :emphasize-lines: 7 static struct bucket_s *table_find(obj_t tbl, obj_t buckets, obj_t key, int add) { struct bucket_s *b; assert(TYPE(tbl) == TYPE_TABLE); b = buckets_find(tbl, tbl->table.buckets, key, add); if ((b == NULL || b->key == NULL || b->key == obj_deleted) && mps_ld_isstale(&tbl->table.ld, arena, key)) { b = table_rehash(tbl, tbl->table.buckets->buckets.length, key); } return b; } After :c:func:`mps_ld_isstale` has returned true, and you've rehashed the table, it might be tempting to repeat the usual address-based lookup. But the MPS does not guarantee that :c:func:`mps_ld_isstale` will not return true again: if the re-hashing took a long time or touched lots of memory, there might have been another garbage collection. (The only time that :c:func:`mps_ld_isstale` guarantees to return false is immediately after :c:func:`mps_ld_reset`.) You might put in a loop here, but for reliability it is better to fall back to a non-address-based version of the computation: here, since ``table_rehash`` has to loop over all the entries in the table anyway, it might as well find the bucket containing ``key`` at the same time and return it. .. warning:: Don't forget to check for staleness when setting a key in a table. If the key is stale then it would be a mistake to add it to the table as then the key will be present twice, at the positions given by the hash of its old and new addresses, thus violating the invariant of the hash table (that a key appears at most once). Similarly, staleness must be tested when deleting a key from a table. .. index:: pair: location dependency; thread safety Thread safety ------------- The functions are all thread-safe with respect to operations on different location dependencies. That means that it is not necessary for threads to interlock if they are performing operations on different location dependencies. The descriptions of the individual functions detail their thread-safety attributes if multiple threads need to access the same location dependency. .. index:: single: location dependency; interface Location dependency interface ----------------------------- .. c:type:: mps_ld_t The type of :term:`location dependencies`. It is a :term:`transparent alias ` for a pointer to :c:type:`mps_ld_s`. A location dependency records the fact that the :term:`client program` depends on the bit patterns of some :term:`references` (and not merely on the identity of the :term:`block` to which the reference refers), and provides a function (:c:func:`mps_ld_isstale`) to find out whether any of these references have been changed because a block has been :term:`moved `. A typical use is in the implementation of a hash table which hashes blocks by hashing their addresses. After a block has moved, the table needs to be rehashed, otherwise it will not be found in the table. .. c:type:: mps_ld_s The type of the structure used to represent a :term:`location dependency`. :: typedef struct mps_ld_s { mps_word_t w0, w1; } mps_ld_s; It is an opaque structure type: it is supplied so that the :term:`client program` can inline the structure (because its size is known), but the client must not access it other than via the functions :c:func:`mps_ld_add`, :c:func:`mps_ld_isstale`, :c:func:`mps_ld_merge`, and :c:func:`mps_ld_reset`. .. c:function:: void mps_ld_add(mps_ld_t ld, mps_arena_t arena, mps_addr_t addr) Add a dependency on a :term:`block` to a :term:`location dependency`. ``ld`` is a location dependency. ``arena`` is the :term:`arena` to which ``addr`` belongs. ``addr`` is the address of the block. After calling :c:func:`mps_ld_add`, and until ``ld`` is passed to :c:func:`mps_ld_reset`, the call :: mps_ld_isstale(ld, arena, addr) will return true if the block has moved. .. note:: It is an error to call :c:func:`mps_ld_add` on the same location dependency with addresses from two different arenas. If you need to test for staleness against multiple arenas, then you need at least one location dependency for each arena. :c:func:`mps_ld_add` is not thread-safe with respect to :c:func:`mps_ld_add`, :c:func:`mps_ld_merge`, or :c:func:`mps_ld_reset` on the same location dependency, but it is thread-safe with respect to :c:func:`mps_ld_isstale` operations. This means that calls to :c:func:`mps_ld_add` from different :term:`threads` must interlock if they are using the same location dependency. The practical upshot of this is that there should be a lock associated with each location dependency. .. c:function:: mps_bool_t mps_ld_isstale(mps_ld_t ld, mps_arena_t arena, mps_addr_t addr) Determine if a dependency on the location of a block in a :term:`location dependency` might be stale with respect to an :term:`arena`. ``ld`` is the location dependency. ``arena`` is the arena to test for staleness against. It must be the same arena that was passed to all calls to :c:func:`mps_ld_add` on ``ld``. ``addr`` is the address of the block that is to be tested for staleness. If there have been no calls to :c:func:`mps_ld_add` on ``ld`` since the last call to :c:func:`mps_ld_reset`, then return false. If the block at ``addr`` was formerly added to the location dependency ``ld`` and subsequently moved by ``arena``, then return true. Otherwise, :c:func:`mps_ld_isstale` may return either true or false. (The function strives to return true in the case where ``addr`` was added to the location dependency and subsquently moved, and false otherwise, but cannot ensure this.) .. note:: :c:func:`mps_ld_isstale` may report a false positive: it may return true in the case where ``addr`` was not added to the location dependency, or in the case where it was added but not moved. It never reports a false negative. :c:func:`mps_ld_isstale` is thread-safe with respect to itself and with respect to :c:func:`mps_ld_add`, but not with respect to :c:func:`mps_ld_reset`. .. c:function:: mps_bool_t mps_ld_isstale_any(mps_ld_t ld, mps_arena_t arena) Determine if a dependency on the location of *any* block in a :term:`location dependency` might be stale with respect to an :term:`arena`. ``ld`` is the location dependency. ``arena`` is the arena to test for staleness against. It must be the same arena that was passed to all calls to :c:func:`mps_ld_add` on ``ld``. If there have been no calls to :c:func:`mps_ld_add` on ``ld`` since the last call to :c:func:`mps_ld_reset`, then return false. If any block added to the location dependency ``ld`` has been moved by ``arena``, then return true. Otherwise, :c:func:`mps_ld_isstale_any` may return either true or false. (The function strives to return true in the case where a block was added to the location dependency and subsquently moved, and false otherwise, but cannot ensure this.) .. note:: :c:func:`mps_ld_isstale_any` has the same thread-safety properties as :c:func:`mps_ld_isstale`. .. c:function:: void mps_ld_merge(mps_ld_t dest_ld, mps_arena_t arena, mps_ld_t src_ld) Merge one :term:`location dependency` into another. ``dest_ld`` is the destination of the merge. ``arena`` is the :term:`arena` . ``src_ld`` is the source of the merge. The effect of this is to add all the addresses that were added to ``src_ld`` to the ``dest_ld``. .. note:: :c:func:`mps_ld_merge` has the same thread-safety properties as :c:func:`mps_ld_add`. .. c:function:: void mps_ld_reset(mps_ld_t ld, mps_arena_t arena) Reset a :term:`location dependency`. ``ld`` is the location dependency. ``arena`` is an arena. After this call, ``ld`` encapsulates no dependencies. After the call to :c:func:`mps_ld_reset` and prior to any call to :c:func:`mps_ld_add` on ``ld``, :c:func:`mps_ld_isstale` on ``ld`` will return false for all arenas. .. note:: :c:func:`mps_ld_reset` is not thread-safe with respect to any other location dependency function.