Rev 53 | Rev 60 | Go to most recent revision | Show entire file | Ignore whitespace | Details | Blame | Last modification | View Log | RSS feed
| Rev 53 | Rev 59 | ||
|---|---|---|---|
| Line 1... | Line 1... | ||
| 1 | <?xml version="1.0" encoding="UTF-8"?> |
1 | <?xml version="1.0" encoding="UTF-8"?> |
| - | 2 | <chapter id="ds"> |
|
| - | 3 | <?dbhtml filename="ds.html"?> |
|
| 2 | 4 | ||
| 3 | <chapter id="ds"><?dbhtml filename="ds.html"?> |
- | |
| 4 | <title>Data structures</title> |
5 | <title>Data structures</title> |
| 5 | - | ||
| 6 | <para> |
- | |
| 7 | There is lots of data that either flows through various HelenOS subsystems |
- | |
| 8 | or is stored directly by them. Each subsystem uses its own data structures |
- | |
| 9 | to represent the data. These data structures need to be kept |
- | |
| 10 | somewhere. In order to work efficiently, HelenOS, and especially its |
- | |
| 11 | kernel, deploys several house keeping data types that are designed |
- | |
| 12 | to faciliate managing other data structures. They serve like generic |
- | |
| 13 | containers. |
- | |
| 14 | </para> |
- | |
| 15 | - | ||
| 16 | <section> |
- | |
| 17 | <title>Lists</title> |
- | |
| 18 | <para> |
- | |
| 19 | HelenOS uses circular doubly linked lists to bind related data |
- | |
| 20 | together. Lists are composed of an independent head and links that are always |
- | |
| 21 | part of the object that is to be put into the list. Adding items to a list |
- | |
| 22 | thus doesn't require any further memory allocations. Head and each link then |
- | |
| 23 | contains forward and backward pointer. An empty list is composed of a sole |
- | |
| 24 | head whose both pointers reference the head itself. The expense of two times |
- | |
| 25 | bigger memory consumption as compared to memory consumption of singly linked |
- | |
| 26 | lists is justified by constant insertion and removal times at random positions |
- | |
| 27 | within the list. |
- | |
| 28 | </para> |
- | |
| 29 | |
- | |
| 30 | <para> |
- | |
| 31 | Lists are frequently used to implement FIFO behaviour (e.g. scheduler run queues |
- | |
| 32 | or synchronization wait queues). Contrary to the FIFO type, which is also supported |
- | |
| 33 | by HelenOS, they don't take up any unused space and are more general. On the |
- | |
| 34 | other hand, they are slower than in-array FIFOs and can be hardly used to implement |
- | |
| 35 | buffers. |
- | |
| 36 | </para> |
- | |
| 37 | - | ||
| 38 | </section> |
- | |
| 39 | - | ||
| 40 | <section> |
- | |
| 41 | <title>FIFO queues</title> |
- | |
| 42 | <para> |
- | |
| 43 | FIFO queues are implemented as either statically or dynamically allocated |
- | |
| 44 | arrays<footnote><para>Depending on the array size.</para></footnote> of some generic type |
- | |
| 45 | with two indices. The first index points to the head of the FIFO queue and the other |
- | |
| 46 | points to the tail thereof. There can be as many items in the FIFO as is the number |
- | |
| 47 | of elements in the array and no more. The indices are taken modulo size of the queue |
- | |
| 48 | because as a consequence of insertions and deletions, the tail can have numericaly |
- | |
| 49 | lower index than the head. |
- | |
| 50 | </para> |
- | |
| 51 | - | ||
| 52 | <para> |
- | |
| 53 | FIFO queues are used, for example, in ASID management code to store inactive ASIDs or |
- | |
| 54 | in userspace keyboard driver to buffer read characters. |
- | |
| 55 | </para> |
- | |
| 56 | </section> |
- | |
| 57 | - | ||
| 58 | <section> |
- | |
| 59 | <title>Hash tables</title> |
- | |
| 60 | <para> |
- | |
| 61 | The kernel, as well as userspace, makes use of the hash table implementation with |
- | |
| 62 | separate chaining. The implementation is very generic in that it forces the user |
- | |
| 63 | to supply methods for computing the hash index, comparing items against a set of keys |
- | |
| 64 | and the item removal callback function. Besides these virtual operations, |
- | |
| 65 | the hash table is composed of a dynamically allocated array of list heads that |
- | |
| 66 | represent each chain, number of chains and the maximal number of keys. |
- | |
| 67 | </para> |
- | |
| 68 | </section> |
- | |
| 69 | - | ||
| 70 | <section> |
- | |
| 71 | <title>B+trees</title> |
- | |
| 72 | <para> |
- | |
| 73 | HelenOS makes use of a variant of B-tree called B+tree. B+trees, in HelenOS implementation, |
- | |
| 74 | are 3-4-5 balanced trees. They are characteristic by the fact that values are kept only in |
- | |
| 75 | the leaf-level nodes and that these nodes are linked together in a list. This data structure |
- | |
| 76 | has logaritmic search, insertion and deletion times and, thanks to the leaf-level list, |
- | |
| 77 | provides fantastic means of walking the nodes containing data. Moreover, B+trees can be used |
- | |
| 78 | for easy storing, resizing and merging of disjunctive intervals. |
- | |
| 79 | </para> |
- | |
| 80 | </section> |
- | |
| 81 | 6 | ||
| - | 7 | <para>There is lots of data that either flows through various HelenOS |
|
| - | 8 | subsystems or is stored directly by them. Each subsystem uses its own data |
|
| - | 9 | structures to represent the data. These data structures need to be kept |
|
| - | 10 | somewhere. In order to work efficiently, HelenOS, and especially its kernel, |
|
| - | 11 | deploys several house keeping data types that are designed to faciliate |
|
| - | 12 | managing other data structures. Most of them serve like generic |
|
| - | 13 | containers.</para> |
|
| - | 14 | ||
| - | 15 | <section> |
|
| - | 16 | <title>Lists</title> |
|
| - | 17 | ||
| - | 18 | <para>HelenOS uses doubly-circularly-linked lists to bind related data |
|
| - | 19 | together. Lists are composed of an independent sentinel node called head |
|
| - | 20 | and links that are always part of the object that is to be put into the |
|
| - | 21 | list. Adding items to a list thus doesn't require any further memory |
|
| - | 22 | allocations. Head and each link then contains forward and backward |
|
| - | 23 | pointer. An empty list is composed of a sole head whose both pointers |
|
| - | 24 | reference the head itself. The expense of two times bigger memory |
|
| - | 25 | consumption as compared to memory consumption of singly linked lists is |
|
| - | 26 | justified by constant insertion and removal times at random positions |
|
| - | 27 | within the list.</para> |
|
| - | 28 | ||
| - | 29 | <para>Lists are frequently used to implement FIFO behaviour (e.g. |
|
| - | 30 | scheduler run queues or synchronization wait queues). Contrary to the FIFO |
|
| - | 31 | type, which is also supported by HelenOS, they don't take up any unused |
|
| - | 32 | space and are more general. On the other hand, they are slower than |
|
| - | 33 | in-array FIFOs and can be hardly used to implement buffers.</para> |
|
| - | 34 | </section> |
|
| - | 35 | ||
| - | 36 | <section> |
|
| - | 37 | <title>FIFO queues</title> |
|
| - | 38 | ||
| - | 39 | <para>FIFO queues are implemented as either statically or dynamically |
|
| - | 40 | allocated arrays<footnote> |
|
| - | 41 | <para>Depending on the array size.</para> |
|
| - | 42 | </footnote> of some generic type with two indices. The first index |
|
| - | 43 | points to the head of the FIFO queue and the other points to the tail |
|
| - | 44 | thereof. There can be as many items in the FIFO as is the number of |
|
| - | 45 | elements in the array and no more. The indices are taken modulo size of |
|
| - | 46 | the queue because as a consequence of insertions and deletions, the tail |
|
| - | 47 | can have numericaly lower index than the head.</para> |
|
| - | 48 | ||
| - | 49 | <para>FIFO queues are used, for example, in ASID management code to store |
|
| - | 50 | inactive ASIDs or in userspace keyboard driver to buffer read |
|
| - | 51 | characters.</para> |
|
| - | 52 | </section> |
|
| - | 53 | ||
| - | 54 | <section> |
|
| - | 55 | <title>Hash tables</title> |
|
| - | 56 | ||
| - | 57 | <para>The kernel, as well as userspace, provides hash table data type |
|
| - | 58 | which uses separate chaining. The hash table type is very generic in that |
|
| - | 59 | it forces the user to supply methods for computing the hash index, |
|
| - | 60 | comparing items against a set of keys and the item removal callback |
|
| - | 61 | function. Besides these virtual operations, the hash table is composed of |
|
| - | 62 | a dynamically allocated array of list heads that represent each chain, |
|
| - | 63 | number of chains and the maximal number of keys.</para> |
|
| - | 64 | </section> |
|
| - | 65 | ||
| - | 66 | <section> |
|
| - | 67 | <title>Bitmaps</title> |
|
| - | 68 | ||
| - | 69 | <para>Several bitmap operations such as clearing or setting consecutive |
|
| - | 70 | bit sequences as well as copying portions of one bitmap into another one |
|
| - | 71 | are supported.</para> |
|
| - | 72 | </section> |
|
| - | 73 | ||
| - | 74 | <section> |
|
| - | 75 | <title>B+trees</title> |
|
| - | 76 | ||
| - | 77 | <para>HelenOS makes use of a variant of B-tree called B+tree. B+trees, in |
|
| - | 78 | HelenOS implementation, are 3-4-5 balanced trees. They are characteristic |
|
| - | 79 | by the fact that values are kept only in the leaf-level nodes and that |
|
| - | 80 | these nodes are linked together in a list. This data structure has |
|
| - | 81 | logaritmic search, insertion and deletion times and, thanks to the |
|
| - | 82 | leaf-level list, provides fantastic means of walking the nodes containing |
|
| - | 83 | data. Moreover, B+trees can be used for easy storing, resizing and merging |
|
| - | 84 | of disjunctive intervals.</para> |
|
| - | 85 | </section> |
|
| 82 | </chapter> |
86 | </chapter> |
| 83 | 87 | ||