MdePkg: introduce BaseOrderedCollectionRedBlackTreeLib library instance
edk2 should have a fast and easy-to-use associative array (a dictionary)
type.
Red-black trees have O(log(n)) worst case time complexity for lookup,
insertion, and deletion (where n is the number of nodes in the tree). They
support minimum and maximum lookup with the same time complexity, hence
red-black trees double as priority queues as well.
Given an iterator to a red-black tree node, getting the next or previous
node (which corresponds to the ordered successor or the predecessor,
respectively, according to the user-defined ordering) is O(log(n)) as
well.
The code reflects the Binary Search Trees and Red-Black Trees chapters of
Introduction to Algorithms, by Cormen, Leiserson, Rivest. One point where
the implementation diverges is the first phase of the Delete() operation.
During that phase, the book's algorithm copies the key and other business
*contents* of the successor node (in case the successor node is affected),
and releases the successor node (instead of the node that the user
requested to delete).
While semantically correct, this would break the above iterator validity
guarantee. This implementation replaces the copying of business contents
between nodes with suitable relinking of nodes, so that all iterators
(except the one whose deletion is being requested) remain valid.
I had written this code originally in approx. 2002. I personally own the
copyright of that version and am hereby relicensing it to Red Hat, under
the BSDL. I had used the original code in a few personal projects since,
for example in the lbzip2-0.x parallel (de)compressor, and now I've ported
the library to edk2. Both during the original implementation and now
during the porting I verified all the cases and their proofs as rigorously
as I could, on paper. (NB, I couldn't find any errors in the 2002 code
now.)
During the porting to edk2, I documented all those cases in code comments
as well (at least half of the source is documentation). These comments are
not blind copies of diagrams from the Algorithms book, nor are they copies
from my original code -- I've done them all fresh now, and I've only
matched the results against the book. Reviewers are invited to sit down
with a pen, some paper, the book, and the code.
The Validate() function verifies the internal red-black properties of the
tree. This function helps with unit testing, and is only invoked when
requested with the PcdValidateOrderedCollection feature flag.
A note about diagrams: edges represented by backslash (\) characters are
often written as "\_", ie. with a following underscore. This is because
line-trailing backslashes are processed very early in compilation (in
translation phase 2), "splicing physical source lines to form logical
source lines". Since the edk2 coding style requires "//" comments for such
documentation, a trailing backslash would splice the next physical line
into the "scope" of the comment. To prevent this, trailing backslashes are
defanged by appending underscores, which should be visually bearable.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Michael Kinney <michael.d.kinney@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15791 6f19259b-4bc3-4df7-8a09-765794883524
2014-08-12 09:29:04 +02:00
|
|
|
/** @file
|
|
|
|
An OrderedCollectionLib instance that provides a red-black tree
|
|
|
|
implementation, and allocates and releases tree nodes with
|
|
|
|
MemoryAllocationLib.
|
|
|
|
|
|
|
|
This library instance is useful when a fast associative container is needed.
|
|
|
|
Worst case time complexity is O(log n) for Find(), Next(), Prev(), Min(),
|
|
|
|
Max(), Insert(), and Delete(), where "n" is the number of elements in the
|
|
|
|
tree. Complete ordered traversal takes O(n) time.
|
|
|
|
|
|
|
|
The implementation is also useful as a fast priority queue.
|
|
|
|
|
|
|
|
Copyright (C) 2014, Red Hat, Inc.
|
2014-08-20 04:06:12 +02:00
|
|
|
Copyright (c) 2014, Intel Corporation. All rights reserved.<BR>
|
MdePkg: introduce BaseOrderedCollectionRedBlackTreeLib library instance
edk2 should have a fast and easy-to-use associative array (a dictionary)
type.
Red-black trees have O(log(n)) worst case time complexity for lookup,
insertion, and deletion (where n is the number of nodes in the tree). They
support minimum and maximum lookup with the same time complexity, hence
red-black trees double as priority queues as well.
Given an iterator to a red-black tree node, getting the next or previous
node (which corresponds to the ordered successor or the predecessor,
respectively, according to the user-defined ordering) is O(log(n)) as
well.
The code reflects the Binary Search Trees and Red-Black Trees chapters of
Introduction to Algorithms, by Cormen, Leiserson, Rivest. One point where
the implementation diverges is the first phase of the Delete() operation.
During that phase, the book's algorithm copies the key and other business
*contents* of the successor node (in case the successor node is affected),
and releases the successor node (instead of the node that the user
requested to delete).
While semantically correct, this would break the above iterator validity
guarantee. This implementation replaces the copying of business contents
between nodes with suitable relinking of nodes, so that all iterators
(except the one whose deletion is being requested) remain valid.
I had written this code originally in approx. 2002. I personally own the
copyright of that version and am hereby relicensing it to Red Hat, under
the BSDL. I had used the original code in a few personal projects since,
for example in the lbzip2-0.x parallel (de)compressor, and now I've ported
the library to edk2. Both during the original implementation and now
during the porting I verified all the cases and their proofs as rigorously
as I could, on paper. (NB, I couldn't find any errors in the 2002 code
now.)
During the porting to edk2, I documented all those cases in code comments
as well (at least half of the source is documentation). These comments are
not blind copies of diagrams from the Algorithms book, nor are they copies
from my original code -- I've done them all fresh now, and I've only
matched the results against the book. Reviewers are invited to sit down
with a pen, some paper, the book, and the code.
The Validate() function verifies the internal red-black properties of the
tree. This function helps with unit testing, and is only invoked when
requested with the PcdValidateOrderedCollection feature flag.
A note about diagrams: edges represented by backslash (\) characters are
often written as "\_", ie. with a following underscore. This is because
line-trailing backslashes are processed very early in compilation (in
translation phase 2), "splicing physical source lines to form logical
source lines". Since the edk2 coding style requires "//" comments for such
documentation, a trailing backslash would splice the next physical line
into the "scope" of the comment. To prevent this, trailing backslashes are
defanged by appending underscores, which should be visually bearable.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Michael Kinney <michael.d.kinney@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15791 6f19259b-4bc3-4df7-8a09-765794883524
2014-08-12 09:29:04 +02:00
|
|
|
|
|
|
|
This program and the accompanying materials are licensed and made available
|
|
|
|
under the terms and conditions of the BSD License that accompanies this
|
|
|
|
distribution. The full text of the license may be found at
|
|
|
|
http://opensource.org/licenses/bsd-license.php.
|
|
|
|
|
|
|
|
THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, WITHOUT
|
|
|
|
WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
|
|
|
|
**/
|
|
|
|
|
|
|
|
#include <Library/OrderedCollectionLib.h>
|
|
|
|
#include <Library/DebugLib.h>
|
|
|
|
#include <Library/MemoryAllocationLib.h>
|
|
|
|
|
|
|
|
typedef enum {
|
|
|
|
RedBlackTreeRed,
|
|
|
|
RedBlackTreeBlack
|
|
|
|
} RED_BLACK_TREE_COLOR;
|
|
|
|
|
|
|
|
//
|
|
|
|
// Incomplete types and convenience typedefs are present in the library class
|
|
|
|
// header. Beside completing the types, we introduce typedefs here that reflect
|
|
|
|
// the implementation closely.
|
|
|
|
//
|
|
|
|
typedef ORDERED_COLLECTION RED_BLACK_TREE;
|
|
|
|
typedef ORDERED_COLLECTION_ENTRY RED_BLACK_TREE_NODE;
|
|
|
|
typedef ORDERED_COLLECTION_USER_COMPARE RED_BLACK_TREE_USER_COMPARE;
|
|
|
|
typedef ORDERED_COLLECTION_KEY_COMPARE RED_BLACK_TREE_KEY_COMPARE;
|
|
|
|
|
|
|
|
struct ORDERED_COLLECTION {
|
|
|
|
RED_BLACK_TREE_NODE *Root;
|
|
|
|
RED_BLACK_TREE_USER_COMPARE UserStructCompare;
|
|
|
|
RED_BLACK_TREE_KEY_COMPARE KeyCompare;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct ORDERED_COLLECTION_ENTRY {
|
|
|
|
VOID *UserStruct;
|
|
|
|
RED_BLACK_TREE_NODE *Parent;
|
|
|
|
RED_BLACK_TREE_NODE *Left;
|
|
|
|
RED_BLACK_TREE_NODE *Right;
|
|
|
|
RED_BLACK_TREE_COLOR Color;
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
Retrieve the user structure linked by the specified tree node.
|
|
|
|
|
|
|
|
Read-only operation.
|
|
|
|
|
|
|
|
@param[in] Node Pointer to the tree node whose associated user structure we
|
|
|
|
want to retrieve. The caller is responsible for passing a
|
|
|
|
non-NULL argument.
|
|
|
|
|
|
|
|
@return Pointer to user structure linked by Node.
|
|
|
|
**/
|
|
|
|
VOID *
|
|
|
|
EFIAPI
|
|
|
|
OrderedCollectionUserStruct (
|
|
|
|
IN CONST RED_BLACK_TREE_NODE *Node
|
|
|
|
)
|
|
|
|
{
|
|
|
|
return Node->UserStruct;
|
|
|
|
}
|
|
|
|
|
2014-08-20 04:06:12 +02:00
|
|
|
/**
|
|
|
|
A slow function that asserts that the tree is a valid red-black tree, and
|
|
|
|
that it orders user structures correctly.
|
MdePkg: introduce BaseOrderedCollectionRedBlackTreeLib library instance
edk2 should have a fast and easy-to-use associative array (a dictionary)
type.
Red-black trees have O(log(n)) worst case time complexity for lookup,
insertion, and deletion (where n is the number of nodes in the tree). They
support minimum and maximum lookup with the same time complexity, hence
red-black trees double as priority queues as well.
Given an iterator to a red-black tree node, getting the next or previous
node (which corresponds to the ordered successor or the predecessor,
respectively, according to the user-defined ordering) is O(log(n)) as
well.
The code reflects the Binary Search Trees and Red-Black Trees chapters of
Introduction to Algorithms, by Cormen, Leiserson, Rivest. One point where
the implementation diverges is the first phase of the Delete() operation.
During that phase, the book's algorithm copies the key and other business
*contents* of the successor node (in case the successor node is affected),
and releases the successor node (instead of the node that the user
requested to delete).
While semantically correct, this would break the above iterator validity
guarantee. This implementation replaces the copying of business contents
between nodes with suitable relinking of nodes, so that all iterators
(except the one whose deletion is being requested) remain valid.
I had written this code originally in approx. 2002. I personally own the
copyright of that version and am hereby relicensing it to Red Hat, under
the BSDL. I had used the original code in a few personal projects since,
for example in the lbzip2-0.x parallel (de)compressor, and now I've ported
the library to edk2. Both during the original implementation and now
during the porting I verified all the cases and their proofs as rigorously
as I could, on paper. (NB, I couldn't find any errors in the 2002 code
now.)
During the porting to edk2, I documented all those cases in code comments
as well (at least half of the source is documentation). These comments are
not blind copies of diagrams from the Algorithms book, nor are they copies
from my original code -- I've done them all fresh now, and I've only
matched the results against the book. Reviewers are invited to sit down
with a pen, some paper, the book, and the code.
The Validate() function verifies the internal red-black properties of the
tree. This function helps with unit testing, and is only invoked when
requested with the PcdValidateOrderedCollection feature flag.
A note about diagrams: edges represented by backslash (\) characters are
often written as "\_", ie. with a following underscore. This is because
line-trailing backslashes are processed very early in compilation (in
translation phase 2), "splicing physical source lines to form logical
source lines". Since the edk2 coding style requires "//" comments for such
documentation, a trailing backslash would splice the next physical line
into the "scope" of the comment. To prevent this, trailing backslashes are
defanged by appending underscores, which should be visually bearable.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Michael Kinney <michael.d.kinney@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15791 6f19259b-4bc3-4df7-8a09-765794883524
2014-08-12 09:29:04 +02:00
|
|
|
|
2014-08-20 04:06:12 +02:00
|
|
|
Read-only operation.
|
|
|
|
|
|
|
|
This function uses the stack for recursion and is not recommended for
|
|
|
|
"production use".
|
|
|
|
|
|
|
|
@param[in] Tree The tree to validate.
|
|
|
|
**/
|
MdePkg: introduce BaseOrderedCollectionRedBlackTreeLib library instance
edk2 should have a fast and easy-to-use associative array (a dictionary)
type.
Red-black trees have O(log(n)) worst case time complexity for lookup,
insertion, and deletion (where n is the number of nodes in the tree). They
support minimum and maximum lookup with the same time complexity, hence
red-black trees double as priority queues as well.
Given an iterator to a red-black tree node, getting the next or previous
node (which corresponds to the ordered successor or the predecessor,
respectively, according to the user-defined ordering) is O(log(n)) as
well.
The code reflects the Binary Search Trees and Red-Black Trees chapters of
Introduction to Algorithms, by Cormen, Leiserson, Rivest. One point where
the implementation diverges is the first phase of the Delete() operation.
During that phase, the book's algorithm copies the key and other business
*contents* of the successor node (in case the successor node is affected),
and releases the successor node (instead of the node that the user
requested to delete).
While semantically correct, this would break the above iterator validity
guarantee. This implementation replaces the copying of business contents
between nodes with suitable relinking of nodes, so that all iterators
(except the one whose deletion is being requested) remain valid.
I had written this code originally in approx. 2002. I personally own the
copyright of that version and am hereby relicensing it to Red Hat, under
the BSDL. I had used the original code in a few personal projects since,
for example in the lbzip2-0.x parallel (de)compressor, and now I've ported
the library to edk2. Both during the original implementation and now
during the porting I verified all the cases and their proofs as rigorously
as I could, on paper. (NB, I couldn't find any errors in the 2002 code
now.)
During the porting to edk2, I documented all those cases in code comments
as well (at least half of the source is documentation). These comments are
not blind copies of diagrams from the Algorithms book, nor are they copies
from my original code -- I've done them all fresh now, and I've only
matched the results against the book. Reviewers are invited to sit down
with a pen, some paper, the book, and the code.
The Validate() function verifies the internal red-black properties of the
tree. This function helps with unit testing, and is only invoked when
requested with the PcdValidateOrderedCollection feature flag.
A note about diagrams: edges represented by backslash (\) characters are
often written as "\_", ie. with a following underscore. This is because
line-trailing backslashes are processed very early in compilation (in
translation phase 2), "splicing physical source lines to form logical
source lines". Since the edk2 coding style requires "//" comments for such
documentation, a trailing backslash would splice the next physical line
into the "scope" of the comment. To prevent this, trailing backslashes are
defanged by appending underscores, which should be visually bearable.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Michael Kinney <michael.d.kinney@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15791 6f19259b-4bc3-4df7-8a09-765794883524
2014-08-12 09:29:04 +02:00
|
|
|
VOID
|
|
|
|
RedBlackTreeValidate (
|
|
|
|
IN CONST RED_BLACK_TREE *Tree
|
|
|
|
);
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
Allocate and initialize the RED_BLACK_TREE structure.
|
|
|
|
|
|
|
|
Allocation occurs via MemoryAllocationLib's AllocatePool() function.
|
|
|
|
|
|
|
|
@param[in] UserStructCompare This caller-provided function will be used to
|
|
|
|
order two user structures linked into the
|
|
|
|
tree, during the insertion procedure.
|
|
|
|
|
|
|
|
@param[in] KeyCompare This caller-provided function will be used to
|
|
|
|
order the standalone search key against user
|
|
|
|
structures linked into the tree, during the
|
|
|
|
lookup procedure.
|
|
|
|
|
|
|
|
@retval NULL If allocation failed.
|
|
|
|
|
|
|
|
@return Pointer to the allocated, initialized RED_BLACK_TREE structure,
|
|
|
|
otherwise.
|
|
|
|
**/
|
|
|
|
RED_BLACK_TREE *
|
|
|
|
EFIAPI
|
|
|
|
OrderedCollectionInit (
|
|
|
|
IN RED_BLACK_TREE_USER_COMPARE UserStructCompare,
|
|
|
|
IN RED_BLACK_TREE_KEY_COMPARE KeyCompare
|
|
|
|
)
|
|
|
|
{
|
|
|
|
RED_BLACK_TREE *Tree;
|
|
|
|
|
|
|
|
Tree = AllocatePool (sizeof *Tree);
|
|
|
|
if (Tree == NULL) {
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
Tree->Root = NULL;
|
|
|
|
Tree->UserStructCompare = UserStructCompare;
|
|
|
|
Tree->KeyCompare = KeyCompare;
|
|
|
|
|
|
|
|
if (FeaturePcdGet (PcdValidateOrderedCollection)) {
|
|
|
|
RedBlackTreeValidate (Tree);
|
|
|
|
}
|
|
|
|
return Tree;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
Check whether the tree is empty (has no nodes).
|
|
|
|
|
|
|
|
Read-only operation.
|
|
|
|
|
|
|
|
@param[in] Tree The tree to check for emptiness.
|
|
|
|
|
|
|
|
@retval TRUE The tree is empty.
|
|
|
|
|
|
|
|
@retval FALSE The tree is not empty.
|
|
|
|
**/
|
|
|
|
BOOLEAN
|
|
|
|
EFIAPI
|
|
|
|
OrderedCollectionIsEmpty (
|
|
|
|
IN CONST RED_BLACK_TREE *Tree
|
|
|
|
)
|
|
|
|
{
|
2014-08-16 18:18:59 +02:00
|
|
|
return (BOOLEAN)(Tree->Root == NULL);
|
MdePkg: introduce BaseOrderedCollectionRedBlackTreeLib library instance
edk2 should have a fast and easy-to-use associative array (a dictionary)
type.
Red-black trees have O(log(n)) worst case time complexity for lookup,
insertion, and deletion (where n is the number of nodes in the tree). They
support minimum and maximum lookup with the same time complexity, hence
red-black trees double as priority queues as well.
Given an iterator to a red-black tree node, getting the next or previous
node (which corresponds to the ordered successor or the predecessor,
respectively, according to the user-defined ordering) is O(log(n)) as
well.
The code reflects the Binary Search Trees and Red-Black Trees chapters of
Introduction to Algorithms, by Cormen, Leiserson, Rivest. One point where
the implementation diverges is the first phase of the Delete() operation.
During that phase, the book's algorithm copies the key and other business
*contents* of the successor node (in case the successor node is affected),
and releases the successor node (instead of the node that the user
requested to delete).
While semantically correct, this would break the above iterator validity
guarantee. This implementation replaces the copying of business contents
between nodes with suitable relinking of nodes, so that all iterators
(except the one whose deletion is being requested) remain valid.
I had written this code originally in approx. 2002. I personally own the
copyright of that version and am hereby relicensing it to Red Hat, under
the BSDL. I had used the original code in a few personal projects since,
for example in the lbzip2-0.x parallel (de)compressor, and now I've ported
the library to edk2. Both during the original implementation and now
during the porting I verified all the cases and their proofs as rigorously
as I could, on paper. (NB, I couldn't find any errors in the 2002 code
now.)
During the porting to edk2, I documented all those cases in code comments
as well (at least half of the source is documentation). These comments are
not blind copies of diagrams from the Algorithms book, nor are they copies
from my original code -- I've done them all fresh now, and I've only
matched the results against the book. Reviewers are invited to sit down
with a pen, some paper, the book, and the code.
The Validate() function verifies the internal red-black properties of the
tree. This function helps with unit testing, and is only invoked when
requested with the PcdValidateOrderedCollection feature flag.
A note about diagrams: edges represented by backslash (\) characters are
often written as "\_", ie. with a following underscore. This is because
line-trailing backslashes are processed very early in compilation (in
translation phase 2), "splicing physical source lines to form logical
source lines". Since the edk2 coding style requires "//" comments for such
documentation, a trailing backslash would splice the next physical line
into the "scope" of the comment. To prevent this, trailing backslashes are
defanged by appending underscores, which should be visually bearable.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Michael Kinney <michael.d.kinney@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15791 6f19259b-4bc3-4df7-8a09-765794883524
2014-08-12 09:29:04 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
Uninitialize and release an empty RED_BLACK_TREE structure.
|
|
|
|
|
|
|
|
Read-write operation.
|
|
|
|
|
|
|
|
Release occurs via MemoryAllocationLib's FreePool() function.
|
|
|
|
|
|
|
|
It is the caller's responsibility to delete all nodes from the tree before
|
|
|
|
calling this function.
|
|
|
|
|
|
|
|
@param[in] Tree The empty tree to uninitialize and release.
|
|
|
|
**/
|
|
|
|
VOID
|
|
|
|
EFIAPI
|
|
|
|
OrderedCollectionUninit (
|
|
|
|
IN RED_BLACK_TREE *Tree
|
|
|
|
)
|
|
|
|
{
|
|
|
|
ASSERT (OrderedCollectionIsEmpty (Tree));
|
|
|
|
FreePool (Tree);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
Look up the tree node that links the user structure that matches the
|
|
|
|
specified standalone key.
|
|
|
|
|
|
|
|
Read-only operation.
|
|
|
|
|
|
|
|
@param[in] Tree The tree to search for StandaloneKey.
|
|
|
|
|
|
|
|
@param[in] StandaloneKey The key to locate among the user structures linked
|
|
|
|
into Tree. StandaloneKey will be passed to
|
|
|
|
Tree->KeyCompare().
|
|
|
|
|
|
|
|
@retval NULL StandaloneKey could not be found.
|
|
|
|
|
|
|
|
@return The tree node that links to the user structure matching
|
|
|
|
StandaloneKey, otherwise.
|
|
|
|
**/
|
|
|
|
RED_BLACK_TREE_NODE *
|
|
|
|
EFIAPI
|
|
|
|
OrderedCollectionFind (
|
|
|
|
IN CONST RED_BLACK_TREE *Tree,
|
|
|
|
IN CONST VOID *StandaloneKey
|
|
|
|
)
|
|
|
|
{
|
|
|
|
RED_BLACK_TREE_NODE *Node;
|
|
|
|
|
|
|
|
Node = Tree->Root;
|
|
|
|
while (Node != NULL) {
|
|
|
|
INTN Result;
|
|
|
|
|
|
|
|
Result = Tree->KeyCompare (StandaloneKey, Node->UserStruct);
|
|
|
|
if (Result == 0) {
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
Node = (Result < 0) ? Node->Left : Node->Right;
|
|
|
|
}
|
|
|
|
return Node;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
Find the tree node of the minimum user structure stored in the tree.
|
|
|
|
|
|
|
|
Read-only operation.
|
|
|
|
|
|
|
|
@param[in] Tree The tree to return the minimum node of. The user structure
|
|
|
|
linked by the minimum node compares less than all other user
|
|
|
|
structures in the tree.
|
|
|
|
|
|
|
|
@retval NULL If Tree is empty.
|
|
|
|
|
|
|
|
@return The tree node that links the minimum user structure, otherwise.
|
|
|
|
**/
|
|
|
|
RED_BLACK_TREE_NODE *
|
|
|
|
EFIAPI
|
|
|
|
OrderedCollectionMin (
|
|
|
|
IN CONST RED_BLACK_TREE *Tree
|
|
|
|
)
|
|
|
|
{
|
|
|
|
RED_BLACK_TREE_NODE *Node;
|
|
|
|
|
|
|
|
Node = Tree->Root;
|
|
|
|
if (Node == NULL) {
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
while (Node->Left != NULL) {
|
|
|
|
Node = Node->Left;
|
|
|
|
}
|
|
|
|
return Node;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
Find the tree node of the maximum user structure stored in the tree.
|
|
|
|
|
|
|
|
Read-only operation.
|
|
|
|
|
|
|
|
@param[in] Tree The tree to return the maximum node of. The user structure
|
|
|
|
linked by the maximum node compares greater than all other
|
|
|
|
user structures in the tree.
|
|
|
|
|
|
|
|
@retval NULL If Tree is empty.
|
|
|
|
|
|
|
|
@return The tree node that links the maximum user structure, otherwise.
|
|
|
|
**/
|
|
|
|
RED_BLACK_TREE_NODE *
|
|
|
|
EFIAPI
|
|
|
|
OrderedCollectionMax (
|
|
|
|
IN CONST RED_BLACK_TREE *Tree
|
|
|
|
)
|
|
|
|
{
|
|
|
|
RED_BLACK_TREE_NODE *Node;
|
|
|
|
|
|
|
|
Node = Tree->Root;
|
|
|
|
if (Node == NULL) {
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
while (Node->Right != NULL) {
|
|
|
|
Node = Node->Right;
|
|
|
|
}
|
|
|
|
return Node;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
Get the tree node of the least user structure that is greater than the one
|
|
|
|
linked by Node.
|
|
|
|
|
|
|
|
Read-only operation.
|
|
|
|
|
|
|
|
@param[in] Node The node to get the successor node of.
|
|
|
|
|
|
|
|
@retval NULL If Node is NULL, or Node is the maximum node of its containing
|
|
|
|
tree (ie. Node has no successor node).
|
|
|
|
|
|
|
|
@return The tree node linking the least user structure that is greater
|
|
|
|
than the one linked by Node, otherwise.
|
|
|
|
**/
|
|
|
|
RED_BLACK_TREE_NODE *
|
|
|
|
EFIAPI
|
|
|
|
OrderedCollectionNext (
|
|
|
|
IN CONST RED_BLACK_TREE_NODE *Node
|
|
|
|
)
|
|
|
|
{
|
|
|
|
RED_BLACK_TREE_NODE *Walk;
|
|
|
|
CONST RED_BLACK_TREE_NODE *Child;
|
|
|
|
|
|
|
|
if (Node == NULL) {
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
//
|
|
|
|
// If Node has a right subtree, then the successor is the minimum node of
|
|
|
|
// that subtree.
|
|
|
|
//
|
|
|
|
Walk = Node->Right;
|
|
|
|
if (Walk != NULL) {
|
|
|
|
while (Walk->Left != NULL) {
|
|
|
|
Walk = Walk->Left;
|
|
|
|
}
|
|
|
|
return Walk;
|
|
|
|
}
|
|
|
|
|
|
|
|
//
|
|
|
|
// Otherwise we have to ascend as long as we're our parent's right child (ie.
|
|
|
|
// ascending to the left).
|
|
|
|
//
|
|
|
|
Child = Node;
|
|
|
|
Walk = Child->Parent;
|
|
|
|
while (Walk != NULL && Child == Walk->Right) {
|
|
|
|
Child = Walk;
|
|
|
|
Walk = Child->Parent;
|
|
|
|
}
|
|
|
|
return Walk;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
Get the tree node of the greatest user structure that is less than the one
|
|
|
|
linked by Node.
|
|
|
|
|
|
|
|
Read-only operation.
|
|
|
|
|
|
|
|
@param[in] Node The node to get the predecessor node of.
|
|
|
|
|
|
|
|
@retval NULL If Node is NULL, or Node is the minimum node of its containing
|
|
|
|
tree (ie. Node has no predecessor node).
|
|
|
|
|
|
|
|
@return The tree node linking the greatest user structure that is less
|
|
|
|
than the one linked by Node, otherwise.
|
|
|
|
**/
|
|
|
|
RED_BLACK_TREE_NODE *
|
|
|
|
EFIAPI
|
|
|
|
OrderedCollectionPrev (
|
|
|
|
IN CONST RED_BLACK_TREE_NODE *Node
|
|
|
|
)
|
|
|
|
{
|
|
|
|
RED_BLACK_TREE_NODE *Walk;
|
|
|
|
CONST RED_BLACK_TREE_NODE *Child;
|
|
|
|
|
|
|
|
if (Node == NULL) {
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
//
|
|
|
|
// If Node has a left subtree, then the predecessor is the maximum node of
|
|
|
|
// that subtree.
|
|
|
|
//
|
|
|
|
Walk = Node->Left;
|
|
|
|
if (Walk != NULL) {
|
|
|
|
while (Walk->Right != NULL) {
|
|
|
|
Walk = Walk->Right;
|
|
|
|
}
|
|
|
|
return Walk;
|
|
|
|
}
|
|
|
|
|
|
|
|
//
|
|
|
|
// Otherwise we have to ascend as long as we're our parent's left child (ie.
|
|
|
|
// ascending to the right).
|
|
|
|
//
|
|
|
|
Child = Node;
|
|
|
|
Walk = Child->Parent;
|
|
|
|
while (Walk != NULL && Child == Walk->Left) {
|
|
|
|
Child = Walk;
|
|
|
|
Walk = Child->Parent;
|
|
|
|
}
|
|
|
|
return Walk;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
Rotate tree nodes around Pivot to the right.
|
|
|
|
|
|
|
|
Parent Parent
|
|
|
|
| |
|
|
|
|
Pivot LeftChild
|
|
|
|
/ . . \_
|
|
|
|
LeftChild Node1 ---> Node2 Pivot
|
|
|
|
. \ / .
|
|
|
|
Node2 LeftRightChild LeftRightChild Node1
|
|
|
|
|
|
|
|
The ordering Node2 < LeftChild < LeftRightChild < Pivot < Node1 is kept
|
|
|
|
intact. Parent (if any) is either at the left extreme or the right extreme of
|
|
|
|
this ordering, and that relation is also kept intact.
|
|
|
|
|
|
|
|
Edges marked with a dot (".") don't change during rotation.
|
|
|
|
|
|
|
|
Internal read-write operation.
|
|
|
|
|
|
|
|
@param[in,out] Pivot The tree node to rotate other nodes right around. It
|
|
|
|
is the caller's responsibility to ensure that
|
|
|
|
Pivot->Left is not NULL.
|
|
|
|
|
|
|
|
@param[out] NewRoot If Pivot has a parent node on input, then the
|
|
|
|
function updates Pivot's original parent on output
|
|
|
|
according to the rotation, and NewRoot is not
|
|
|
|
accessed.
|
|
|
|
|
|
|
|
If Pivot has no parent node on input (ie. Pivot is
|
|
|
|
the root of the tree), then the function stores the
|
|
|
|
new root node of the tree in NewRoot.
|
|
|
|
**/
|
|
|
|
VOID
|
|
|
|
RedBlackTreeRotateRight (
|
|
|
|
IN OUT RED_BLACK_TREE_NODE *Pivot,
|
|
|
|
OUT RED_BLACK_TREE_NODE **NewRoot
|
|
|
|
)
|
|
|
|
{
|
2014-08-20 04:06:12 +02:00
|
|
|
RED_BLACK_TREE_NODE *Parent;
|
|
|
|
RED_BLACK_TREE_NODE *LeftChild;
|
|
|
|
RED_BLACK_TREE_NODE *LeftRightChild;
|
MdePkg: introduce BaseOrderedCollectionRedBlackTreeLib library instance
edk2 should have a fast and easy-to-use associative array (a dictionary)
type.
Red-black trees have O(log(n)) worst case time complexity for lookup,
insertion, and deletion (where n is the number of nodes in the tree). They
support minimum and maximum lookup with the same time complexity, hence
red-black trees double as priority queues as well.
Given an iterator to a red-black tree node, getting the next or previous
node (which corresponds to the ordered successor or the predecessor,
respectively, according to the user-defined ordering) is O(log(n)) as
well.
The code reflects the Binary Search Trees and Red-Black Trees chapters of
Introduction to Algorithms, by Cormen, Leiserson, Rivest. One point where
the implementation diverges is the first phase of the Delete() operation.
During that phase, the book's algorithm copies the key and other business
*contents* of the successor node (in case the successor node is affected),
and releases the successor node (instead of the node that the user
requested to delete).
While semantically correct, this would break the above iterator validity
guarantee. This implementation replaces the copying of business contents
between nodes with suitable relinking of nodes, so that all iterators
(except the one whose deletion is being requested) remain valid.
I had written this code originally in approx. 2002. I personally own the
copyright of that version and am hereby relicensing it to Red Hat, under
the BSDL. I had used the original code in a few personal projects since,
for example in the lbzip2-0.x parallel (de)compressor, and now I've ported
the library to edk2. Both during the original implementation and now
during the porting I verified all the cases and their proofs as rigorously
as I could, on paper. (NB, I couldn't find any errors in the 2002 code
now.)
During the porting to edk2, I documented all those cases in code comments
as well (at least half of the source is documentation). These comments are
not blind copies of diagrams from the Algorithms book, nor are they copies
from my original code -- I've done them all fresh now, and I've only
matched the results against the book. Reviewers are invited to sit down
with a pen, some paper, the book, and the code.
The Validate() function verifies the internal red-black properties of the
tree. This function helps with unit testing, and is only invoked when
requested with the PcdValidateOrderedCollection feature flag.
A note about diagrams: edges represented by backslash (\) characters are
often written as "\_", ie. with a following underscore. This is because
line-trailing backslashes are processed very early in compilation (in
translation phase 2), "splicing physical source lines to form logical
source lines". Since the edk2 coding style requires "//" comments for such
documentation, a trailing backslash would splice the next physical line
into the "scope" of the comment. To prevent this, trailing backslashes are
defanged by appending underscores, which should be visually bearable.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Michael Kinney <michael.d.kinney@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15791 6f19259b-4bc3-4df7-8a09-765794883524
2014-08-12 09:29:04 +02:00
|
|
|
|
|
|
|
Parent = Pivot->Parent;
|
|
|
|
LeftChild = Pivot->Left;
|
|
|
|
LeftRightChild = LeftChild->Right;
|
|
|
|
|
|
|
|
Pivot->Left = LeftRightChild;
|
|
|
|
if (LeftRightChild != NULL) {
|
|
|
|
LeftRightChild->Parent = Pivot;
|
|
|
|
}
|
|
|
|
LeftChild->Parent = Parent;
|
|
|
|
if (Parent == NULL) {
|
|
|
|
*NewRoot = LeftChild;
|
|
|
|
} else {
|
|
|
|
if (Pivot == Parent->Left) {
|
|
|
|
Parent->Left = LeftChild;
|
|
|
|
} else {
|
|
|
|
Parent->Right = LeftChild;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
LeftChild->Right = Pivot;
|
|
|
|
Pivot->Parent = LeftChild;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
Rotate tree nodes around Pivot to the left.
|
|
|
|
|
|
|
|
Parent Parent
|
|
|
|
| |
|
|
|
|
Pivot RightChild
|
|
|
|
. \ / .
|
|
|
|
Node1 RightChild ---> Pivot Node2
|
|
|
|
/. . \_
|
|
|
|
RightLeftChild Node2 Node1 RightLeftChild
|
|
|
|
|
|
|
|
The ordering Node1 < Pivot < RightLeftChild < RightChild < Node2 is kept
|
|
|
|
intact. Parent (if any) is either at the left extreme or the right extreme of
|
|
|
|
this ordering, and that relation is also kept intact.
|
|
|
|
|
|
|
|
Edges marked with a dot (".") don't change during rotation.
|
|
|
|
|
|
|
|
Internal read-write operation.
|
|
|
|
|
|
|
|
@param[in,out] Pivot The tree node to rotate other nodes left around. It
|
|
|
|
is the caller's responsibility to ensure that
|
|
|
|
Pivot->Right is not NULL.
|
|
|
|
|
|
|
|
@param[out] NewRoot If Pivot has a parent node on input, then the
|
|
|
|
function updates Pivot's original parent on output
|
|
|
|
according to the rotation, and NewRoot is not
|
|
|
|
accessed.
|
|
|
|
|
|
|
|
If Pivot has no parent node on input (ie. Pivot is
|
|
|
|
the root of the tree), then the function stores the
|
|
|
|
new root node of the tree in NewRoot.
|
|
|
|
**/
|
|
|
|
VOID
|
|
|
|
RedBlackTreeRotateLeft (
|
|
|
|
IN OUT RED_BLACK_TREE_NODE *Pivot,
|
|
|
|
OUT RED_BLACK_TREE_NODE **NewRoot
|
|
|
|
)
|
|
|
|
{
|
2014-08-20 04:06:12 +02:00
|
|
|
RED_BLACK_TREE_NODE *Parent;
|
|
|
|
RED_BLACK_TREE_NODE *RightChild;
|
|
|
|
RED_BLACK_TREE_NODE *RightLeftChild;
|
MdePkg: introduce BaseOrderedCollectionRedBlackTreeLib library instance
edk2 should have a fast and easy-to-use associative array (a dictionary)
type.
Red-black trees have O(log(n)) worst case time complexity for lookup,
insertion, and deletion (where n is the number of nodes in the tree). They
support minimum and maximum lookup with the same time complexity, hence
red-black trees double as priority queues as well.
Given an iterator to a red-black tree node, getting the next or previous
node (which corresponds to the ordered successor or the predecessor,
respectively, according to the user-defined ordering) is O(log(n)) as
well.
The code reflects the Binary Search Trees and Red-Black Trees chapters of
Introduction to Algorithms, by Cormen, Leiserson, Rivest. One point where
the implementation diverges is the first phase of the Delete() operation.
During that phase, the book's algorithm copies the key and other business
*contents* of the successor node (in case the successor node is affected),
and releases the successor node (instead of the node that the user
requested to delete).
While semantically correct, this would break the above iterator validity
guarantee. This implementation replaces the copying of business contents
between nodes with suitable relinking of nodes, so that all iterators
(except the one whose deletion is being requested) remain valid.
I had written this code originally in approx. 2002. I personally own the
copyright of that version and am hereby relicensing it to Red Hat, under
the BSDL. I had used the original code in a few personal projects since,
for example in the lbzip2-0.x parallel (de)compressor, and now I've ported
the library to edk2. Both during the original implementation and now
during the porting I verified all the cases and their proofs as rigorously
as I could, on paper. (NB, I couldn't find any errors in the 2002 code
now.)
During the porting to edk2, I documented all those cases in code comments
as well (at least half of the source is documentation). These comments are
not blind copies of diagrams from the Algorithms book, nor are they copies
from my original code -- I've done them all fresh now, and I've only
matched the results against the book. Reviewers are invited to sit down
with a pen, some paper, the book, and the code.
The Validate() function verifies the internal red-black properties of the
tree. This function helps with unit testing, and is only invoked when
requested with the PcdValidateOrderedCollection feature flag.
A note about diagrams: edges represented by backslash (\) characters are
often written as "\_", ie. with a following underscore. This is because
line-trailing backslashes are processed very early in compilation (in
translation phase 2), "splicing physical source lines to form logical
source lines". Since the edk2 coding style requires "//" comments for such
documentation, a trailing backslash would splice the next physical line
into the "scope" of the comment. To prevent this, trailing backslashes are
defanged by appending underscores, which should be visually bearable.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Michael Kinney <michael.d.kinney@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15791 6f19259b-4bc3-4df7-8a09-765794883524
2014-08-12 09:29:04 +02:00
|
|
|
|
|
|
|
Parent = Pivot->Parent;
|
|
|
|
RightChild = Pivot->Right;
|
|
|
|
RightLeftChild = RightChild->Left;
|
|
|
|
|
|
|
|
Pivot->Right = RightLeftChild;
|
|
|
|
if (RightLeftChild != NULL) {
|
|
|
|
RightLeftChild->Parent = Pivot;
|
|
|
|
}
|
|
|
|
RightChild->Parent = Parent;
|
|
|
|
if (Parent == NULL) {
|
|
|
|
*NewRoot = RightChild;
|
|
|
|
} else {
|
|
|
|
if (Pivot == Parent->Left) {
|
|
|
|
Parent->Left = RightChild;
|
|
|
|
} else {
|
|
|
|
Parent->Right = RightChild;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
RightChild->Left = Pivot;
|
|
|
|
Pivot->Parent = RightChild;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
Insert (link) a user structure into the tree.
|
|
|
|
|
|
|
|
Read-write operation.
|
|
|
|
|
|
|
|
This function allocates the new tree node with MemoryAllocationLib's
|
|
|
|
AllocatePool() function.
|
|
|
|
|
|
|
|
@param[in,out] Tree The tree to insert UserStruct into.
|
|
|
|
|
|
|
|
@param[out] Node The meaning of this optional, output-only
|
|
|
|
parameter depends on the return value of the
|
|
|
|
function.
|
|
|
|
|
|
|
|
When insertion is successful (RETURN_SUCCESS),
|
|
|
|
Node is set on output to the new tree node that
|
|
|
|
now links UserStruct.
|
|
|
|
|
|
|
|
When insertion fails due to lack of memory
|
|
|
|
(RETURN_OUT_OF_RESOURCES), Node is not changed.
|
|
|
|
|
|
|
|
When insertion fails due to key collision (ie.
|
|
|
|
another user structure is already in the tree that
|
|
|
|
compares equal to UserStruct), with return value
|
|
|
|
RETURN_ALREADY_STARTED, then Node is set on output
|
|
|
|
to the node that links the colliding user
|
|
|
|
structure. This enables "find-or-insert" in one
|
|
|
|
function call, or helps with later removal of the
|
|
|
|
colliding element.
|
|
|
|
|
|
|
|
@param[in] UserStruct The user structure to link into the tree.
|
|
|
|
UserStruct is ordered against in-tree user
|
|
|
|
structures with the Tree->UserStructCompare()
|
|
|
|
function.
|
|
|
|
|
|
|
|
@retval RETURN_SUCCESS Insertion successful. A new tree node has
|
|
|
|
been allocated, linking UserStruct. The new
|
|
|
|
tree node is reported back in Node (if the
|
|
|
|
caller requested it).
|
|
|
|
|
|
|
|
Existing RED_BLACK_TREE_NODE pointers into
|
|
|
|
Tree remain valid. For example, on-going
|
|
|
|
iterations in the caller can continue with
|
|
|
|
OrderedCollectionNext() /
|
|
|
|
OrderedCollectionPrev(), and they will
|
|
|
|
return the new node at some point if user
|
|
|
|
structure order dictates it.
|
|
|
|
|
|
|
|
@retval RETURN_OUT_OF_RESOURCES AllocatePool() failed to allocate memory for
|
|
|
|
the new tree node. The tree has not been
|
|
|
|
changed. Existing RED_BLACK_TREE_NODE
|
|
|
|
pointers into Tree remain valid.
|
|
|
|
|
|
|
|
@retval RETURN_ALREADY_STARTED A user structure has been found in the tree
|
|
|
|
that compares equal to UserStruct. The node
|
|
|
|
linking the colliding user structure is
|
|
|
|
reported back in Node (if the caller
|
|
|
|
requested it). The tree has not been
|
|
|
|
changed. Existing RED_BLACK_TREE_NODE
|
|
|
|
pointers into Tree remain valid.
|
|
|
|
**/
|
|
|
|
RETURN_STATUS
|
|
|
|
EFIAPI
|
|
|
|
OrderedCollectionInsert (
|
|
|
|
IN OUT RED_BLACK_TREE *Tree,
|
|
|
|
OUT RED_BLACK_TREE_NODE **Node OPTIONAL,
|
|
|
|
IN VOID *UserStruct
|
|
|
|
)
|
|
|
|
{
|
2014-08-20 04:06:12 +02:00
|
|
|
RED_BLACK_TREE_NODE *Tmp;
|
|
|
|
RED_BLACK_TREE_NODE *Parent;
|
MdePkg: introduce BaseOrderedCollectionRedBlackTreeLib library instance
edk2 should have a fast and easy-to-use associative array (a dictionary)
type.
Red-black trees have O(log(n)) worst case time complexity for lookup,
insertion, and deletion (where n is the number of nodes in the tree). They
support minimum and maximum lookup with the same time complexity, hence
red-black trees double as priority queues as well.
Given an iterator to a red-black tree node, getting the next or previous
node (which corresponds to the ordered successor or the predecessor,
respectively, according to the user-defined ordering) is O(log(n)) as
well.
The code reflects the Binary Search Trees and Red-Black Trees chapters of
Introduction to Algorithms, by Cormen, Leiserson, Rivest. One point where
the implementation diverges is the first phase of the Delete() operation.
During that phase, the book's algorithm copies the key and other business
*contents* of the successor node (in case the successor node is affected),
and releases the successor node (instead of the node that the user
requested to delete).
While semantically correct, this would break the above iterator validity
guarantee. This implementation replaces the copying of business contents
between nodes with suitable relinking of nodes, so that all iterators
(except the one whose deletion is being requested) remain valid.
I had written this code originally in approx. 2002. I personally own the
copyright of that version and am hereby relicensing it to Red Hat, under
the BSDL. I had used the original code in a few personal projects since,
for example in the lbzip2-0.x parallel (de)compressor, and now I've ported
the library to edk2. Both during the original implementation and now
during the porting I verified all the cases and their proofs as rigorously
as I could, on paper. (NB, I couldn't find any errors in the 2002 code
now.)
During the porting to edk2, I documented all those cases in code comments
as well (at least half of the source is documentation). These comments are
not blind copies of diagrams from the Algorithms book, nor are they copies
from my original code -- I've done them all fresh now, and I've only
matched the results against the book. Reviewers are invited to sit down
with a pen, some paper, the book, and the code.
The Validate() function verifies the internal red-black properties of the
tree. This function helps with unit testing, and is only invoked when
requested with the PcdValidateOrderedCollection feature flag.
A note about diagrams: edges represented by backslash (\) characters are
often written as "\_", ie. with a following underscore. This is because
line-trailing backslashes are processed very early in compilation (in
translation phase 2), "splicing physical source lines to form logical
source lines". Since the edk2 coding style requires "//" comments for such
documentation, a trailing backslash would splice the next physical line
into the "scope" of the comment. To prevent this, trailing backslashes are
defanged by appending underscores, which should be visually bearable.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Michael Kinney <michael.d.kinney@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15791 6f19259b-4bc3-4df7-8a09-765794883524
2014-08-12 09:29:04 +02:00
|
|
|
INTN Result;
|
|
|
|
RETURN_STATUS Status;
|
|
|
|
RED_BLACK_TREE_NODE *NewRoot;
|
|
|
|
|
|
|
|
Tmp = Tree->Root;
|
|
|
|
Parent = NULL;
|
2014-08-16 18:18:53 +02:00
|
|
|
Result = 0;
|
MdePkg: introduce BaseOrderedCollectionRedBlackTreeLib library instance
edk2 should have a fast and easy-to-use associative array (a dictionary)
type.
Red-black trees have O(log(n)) worst case time complexity for lookup,
insertion, and deletion (where n is the number of nodes in the tree). They
support minimum and maximum lookup with the same time complexity, hence
red-black trees double as priority queues as well.
Given an iterator to a red-black tree node, getting the next or previous
node (which corresponds to the ordered successor or the predecessor,
respectively, according to the user-defined ordering) is O(log(n)) as
well.
The code reflects the Binary Search Trees and Red-Black Trees chapters of
Introduction to Algorithms, by Cormen, Leiserson, Rivest. One point where
the implementation diverges is the first phase of the Delete() operation.
During that phase, the book's algorithm copies the key and other business
*contents* of the successor node (in case the successor node is affected),
and releases the successor node (instead of the node that the user
requested to delete).
While semantically correct, this would break the above iterator validity
guarantee. This implementation replaces the copying of business contents
between nodes with suitable relinking of nodes, so that all iterators
(except the one whose deletion is being requested) remain valid.
I had written this code originally in approx. 2002. I personally own the
copyright of that version and am hereby relicensing it to Red Hat, under
the BSDL. I had used the original code in a few personal projects since,
for example in the lbzip2-0.x parallel (de)compressor, and now I've ported
the library to edk2. Both during the original implementation and now
during the porting I verified all the cases and their proofs as rigorously
as I could, on paper. (NB, I couldn't find any errors in the 2002 code
now.)
During the porting to edk2, I documented all those cases in code comments
as well (at least half of the source is documentation). These comments are
not blind copies of diagrams from the Algorithms book, nor are they copies
from my original code -- I've done them all fresh now, and I've only
matched the results against the book. Reviewers are invited to sit down
with a pen, some paper, the book, and the code.
The Validate() function verifies the internal red-black properties of the
tree. This function helps with unit testing, and is only invoked when
requested with the PcdValidateOrderedCollection feature flag.
A note about diagrams: edges represented by backslash (\) characters are
often written as "\_", ie. with a following underscore. This is because
line-trailing backslashes are processed very early in compilation (in
translation phase 2), "splicing physical source lines to form logical
source lines". Since the edk2 coding style requires "//" comments for such
documentation, a trailing backslash would splice the next physical line
into the "scope" of the comment. To prevent this, trailing backslashes are
defanged by appending underscores, which should be visually bearable.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Michael Kinney <michael.d.kinney@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15791 6f19259b-4bc3-4df7-8a09-765794883524
2014-08-12 09:29:04 +02:00
|
|
|
|
|
|
|
//
|
|
|
|
// First look for a collision, saving the last examined node for the case
|
|
|
|
// when there's no collision.
|
|
|
|
//
|
|
|
|
while (Tmp != NULL) {
|
|
|
|
Result = Tree->UserStructCompare (UserStruct, Tmp->UserStruct);
|
|
|
|
if (Result == 0) {
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
Parent = Tmp;
|
|
|
|
Tmp = (Result < 0) ? Tmp->Left : Tmp->Right;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (Tmp != NULL) {
|
|
|
|
if (Node != NULL) {
|
|
|
|
*Node = Tmp;
|
|
|
|
}
|
|
|
|
Status = RETURN_ALREADY_STARTED;
|
|
|
|
goto Done;
|
|
|
|
}
|
|
|
|
|
|
|
|
//
|
|
|
|
// no collision, allocate a new node
|
|
|
|
//
|
|
|
|
Tmp = AllocatePool (sizeof *Tmp);
|
|
|
|
if (Tmp == NULL) {
|
|
|
|
Status = RETURN_OUT_OF_RESOURCES;
|
|
|
|
goto Done;
|
|
|
|
}
|
|
|
|
if (Node != NULL) {
|
|
|
|
*Node = Tmp;
|
|
|
|
}
|
|
|
|
|
|
|
|
//
|
|
|
|
// reference the user structure from the node
|
|
|
|
//
|
|
|
|
Tmp->UserStruct = UserStruct;
|
|
|
|
|
|
|
|
//
|
|
|
|
// Link the node as a child to the correct side of the parent.
|
|
|
|
// If there's no parent, the new node is the root node in the tree.
|
|
|
|
//
|
|
|
|
Tmp->Parent = Parent;
|
|
|
|
Tmp->Left = NULL;
|
|
|
|
Tmp->Right = NULL;
|
|
|
|
if (Parent == NULL) {
|
|
|
|
Tree->Root = Tmp;
|
|
|
|
Tmp->Color = RedBlackTreeBlack;
|
|
|
|
Status = RETURN_SUCCESS;
|
|
|
|
goto Done;
|
|
|
|
}
|
|
|
|
if (Result < 0) {
|
|
|
|
Parent->Left = Tmp;
|
|
|
|
} else {
|
|
|
|
Parent->Right = Tmp;
|
|
|
|
}
|
|
|
|
Tmp->Color = RedBlackTreeRed;
|
|
|
|
|
|
|
|
//
|
|
|
|
// Red-black tree properties:
|
|
|
|
//
|
|
|
|
// #1 Each node is either red or black (RED_BLACK_TREE_NODE.Color).
|
|
|
|
//
|
|
|
|
// #2 Each leaf (ie. a pseudo-node pointed-to by a NULL valued
|
|
|
|
// RED_BLACK_TREE_NODE.Left or RED_BLACK_TREE_NODE.Right field) is black.
|
|
|
|
//
|
|
|
|
// #3 Each red node has two black children.
|
|
|
|
//
|
|
|
|
// #4 For any node N, and for any leaves L1 and L2 reachable from N, the
|
|
|
|
// paths N..L1 and N..L2 contain the same number of black nodes.
|
|
|
|
//
|
|
|
|
// #5 The root node is black.
|
|
|
|
//
|
|
|
|
// By replacing a leaf with a red node above, only property #3 may have been
|
|
|
|
// broken. (Note that this is the only edge across which property #3 might
|
|
|
|
// not hold in the entire tree.) Restore property #3.
|
|
|
|
//
|
|
|
|
|
|
|
|
NewRoot = Tree->Root;
|
|
|
|
while (Tmp != NewRoot && Parent->Color == RedBlackTreeRed) {
|
2014-08-20 04:06:12 +02:00
|
|
|
RED_BLACK_TREE_NODE *GrandParent;
|
|
|
|
RED_BLACK_TREE_NODE *Uncle;
|
MdePkg: introduce BaseOrderedCollectionRedBlackTreeLib library instance
edk2 should have a fast and easy-to-use associative array (a dictionary)
type.
Red-black trees have O(log(n)) worst case time complexity for lookup,
insertion, and deletion (where n is the number of nodes in the tree). They
support minimum and maximum lookup with the same time complexity, hence
red-black trees double as priority queues as well.
Given an iterator to a red-black tree node, getting the next or previous
node (which corresponds to the ordered successor or the predecessor,
respectively, according to the user-defined ordering) is O(log(n)) as
well.
The code reflects the Binary Search Trees and Red-Black Trees chapters of
Introduction to Algorithms, by Cormen, Leiserson, Rivest. One point where
the implementation diverges is the first phase of the Delete() operation.
During that phase, the book's algorithm copies the key and other business
*contents* of the successor node (in case the successor node is affected),
and releases the successor node (instead of the node that the user
requested to delete).
While semantically correct, this would break the above iterator validity
guarantee. This implementation replaces the copying of business contents
between nodes with suitable relinking of nodes, so that all iterators
(except the one whose deletion is being requested) remain valid.
I had written this code originally in approx. 2002. I personally own the
copyright of that version and am hereby relicensing it to Red Hat, under
the BSDL. I had used the original code in a few personal projects since,
for example in the lbzip2-0.x parallel (de)compressor, and now I've ported
the library to edk2. Both during the original implementation and now
during the porting I verified all the cases and their proofs as rigorously
as I could, on paper. (NB, I couldn't find any errors in the 2002 code
now.)
During the porting to edk2, I documented all those cases in code comments
as well (at least half of the source is documentation). These comments are
not blind copies of diagrams from the Algorithms book, nor are they copies
from my original code -- I've done them all fresh now, and I've only
matched the results against the book. Reviewers are invited to sit down
with a pen, some paper, the book, and the code.
The Validate() function verifies the internal red-black properties of the
tree. This function helps with unit testing, and is only invoked when
requested with the PcdValidateOrderedCollection feature flag.
A note about diagrams: edges represented by backslash (\) characters are
often written as "\_", ie. with a following underscore. This is because
line-trailing backslashes are processed very early in compilation (in
translation phase 2), "splicing physical source lines to form logical
source lines". Since the edk2 coding style requires "//" comments for such
documentation, a trailing backslash would splice the next physical line
into the "scope" of the comment. To prevent this, trailing backslashes are
defanged by appending underscores, which should be visually bearable.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Michael Kinney <michael.d.kinney@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15791 6f19259b-4bc3-4df7-8a09-765794883524
2014-08-12 09:29:04 +02:00
|
|
|
|
|
|
|
//
|
|
|
|
// Tmp is not the root node. Tmp is red. Tmp's parent is red. (Breaking
|
|
|
|
// property #3.)
|
|
|
|
//
|
|
|
|
// Due to property #5, Tmp's parent cannot be the root node, hence Tmp's
|
|
|
|
// grandparent exists.
|
|
|
|
//
|
|
|
|
// Tmp's grandparent is black, because property #3 is only broken between
|
|
|
|
// Tmp and Tmp's parent.
|
|
|
|
//
|
|
|
|
GrandParent = Parent->Parent;
|
|
|
|
|
|
|
|
if (Parent == GrandParent->Left) {
|
|
|
|
Uncle = GrandParent->Right;
|
|
|
|
if (Uncle != NULL && Uncle->Color == RedBlackTreeRed) {
|
|
|
|
//
|
|
|
|
// GrandParent (black)
|
|
|
|
// / \_
|
|
|
|
// Parent (red) Uncle (red)
|
|
|
|
// |
|
|
|
|
// Tmp (red)
|
|
|
|
//
|
|
|
|
|
|
|
|
Parent->Color = RedBlackTreeBlack;
|
|
|
|
Uncle->Color = RedBlackTreeBlack;
|
|
|
|
GrandParent->Color = RedBlackTreeRed;
|
|
|
|
|
|
|
|
//
|
|
|
|
// GrandParent (red)
|
|
|
|
// / \_
|
|
|
|
// Parent (black) Uncle (black)
|
|
|
|
// |
|
|
|
|
// Tmp (red)
|
|
|
|
//
|
|
|
|
// We restored property #3 between Tmp and Tmp's parent, without
|
|
|
|
// breaking property #4. However, we may have broken property #3
|
|
|
|
// between Tmp's grandparent and Tmp's great-grandparent (if any), so
|
|
|
|
// repeat the loop for Tmp's grandparent.
|
|
|
|
//
|
|
|
|
// If Tmp's grandparent has no parent, then the loop will terminate,
|
|
|
|
// and we will have broken property #5, by coloring the root red. We'll
|
|
|
|
// restore property #5 after the loop, without breaking any others.
|
|
|
|
//
|
|
|
|
Tmp = GrandParent;
|
|
|
|
Parent = Tmp->Parent;
|
|
|
|
} else {
|
|
|
|
//
|
|
|
|
// Tmp's uncle is black (satisfied by the case too when Tmp's uncle is
|
|
|
|
// NULL, see property #2).
|
|
|
|
//
|
|
|
|
|
|
|
|
if (Tmp == Parent->Right) {
|
|
|
|
//
|
|
|
|
// GrandParent (black): D
|
|
|
|
// / \_
|
|
|
|
// Parent (red): A Uncle (black): E
|
|
|
|
// \_
|
|
|
|
// Tmp (red): B
|
|
|
|
// \_
|
|
|
|
// black: C
|
|
|
|
//
|
|
|
|
// Rotate left, pivoting on node A. This keeps the breakage of
|
|
|
|
// property #3 in the same spot, and keeps other properties intact
|
|
|
|
// (because both Tmp and its parent are red).
|
|
|
|
//
|
|
|
|
Tmp = Parent;
|
|
|
|
RedBlackTreeRotateLeft (Tmp, &NewRoot);
|
|
|
|
Parent = Tmp->Parent;
|
|
|
|
|
|
|
|
//
|
|
|
|
// With the rotation we reached the same configuration as if Tmp had
|
|
|
|
// been a left child to begin with.
|
|
|
|
//
|
|
|
|
// GrandParent (black): D
|
|
|
|
// / \_
|
|
|
|
// Parent (red): B Uncle (black): E
|
|
|
|
// / \_
|
|
|
|
// Tmp (red): A black: C
|
|
|
|
//
|
|
|
|
ASSERT (GrandParent == Parent->Parent);
|
|
|
|
}
|
|
|
|
|
|
|
|
Parent->Color = RedBlackTreeBlack;
|
|
|
|
GrandParent->Color = RedBlackTreeRed;
|
|
|
|
|
|
|
|
//
|
|
|
|
// Property #3 is now restored, but we've broken property #4. Namely,
|
|
|
|
// paths going through node E now see a decrease in black count, while
|
|
|
|
// paths going through node B don't.
|
|
|
|
//
|
|
|
|
// GrandParent (red): D
|
|
|
|
// / \_
|
|
|
|
// Parent (black): B Uncle (black): E
|
|
|
|
// / \_
|
|
|
|
// Tmp (red): A black: C
|
|
|
|
//
|
|
|
|
|
|
|
|
RedBlackTreeRotateRight (GrandParent, &NewRoot);
|
|
|
|
|
|
|
|
//
|
|
|
|
// Property #4 has been restored for node E, and preserved for others.
|
|
|
|
//
|
|
|
|
// Parent (black): B
|
|
|
|
// / \_
|
|
|
|
// Tmp (red): A [GrandParent] (red): D
|
|
|
|
// / \_
|
|
|
|
// black: C [Uncle] (black): E
|
|
|
|
//
|
|
|
|
// This configuration terminates the loop because Tmp's parent is now
|
|
|
|
// black.
|
|
|
|
//
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
//
|
|
|
|
// Symmetrical to the other branch.
|
|
|
|
//
|
|
|
|
Uncle = GrandParent->Left;
|
|
|
|
if (Uncle != NULL && Uncle->Color == RedBlackTreeRed) {
|
|
|
|
Parent->Color = RedBlackTreeBlack;
|
|
|
|
Uncle->Color = RedBlackTreeBlack;
|
|
|
|
GrandParent->Color = RedBlackTreeRed;
|
|
|
|
Tmp = GrandParent;
|
|
|
|
Parent = Tmp->Parent;
|
|
|
|
} else {
|
|
|
|
if (Tmp == Parent->Left) {
|
|
|
|
Tmp = Parent;
|
|
|
|
RedBlackTreeRotateRight (Tmp, &NewRoot);
|
|
|
|
Parent = Tmp->Parent;
|
|
|
|
ASSERT (GrandParent == Parent->Parent);
|
|
|
|
}
|
|
|
|
Parent->Color = RedBlackTreeBlack;
|
|
|
|
GrandParent->Color = RedBlackTreeRed;
|
|
|
|
RedBlackTreeRotateLeft (GrandParent, &NewRoot);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
NewRoot->Color = RedBlackTreeBlack;
|
|
|
|
Tree->Root = NewRoot;
|
|
|
|
Status = RETURN_SUCCESS;
|
|
|
|
|
|
|
|
Done:
|
|
|
|
if (FeaturePcdGet (PcdValidateOrderedCollection)) {
|
|
|
|
RedBlackTreeValidate (Tree);
|
|
|
|
}
|
|
|
|
return Status;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
Check if a node is black, allowing for leaf nodes (see property #2).
|
|
|
|
|
|
|
|
This is a convenience shorthand.
|
|
|
|
|
|
|
|
param[in] Node The node to check. Node may be NULL, corresponding to a leaf.
|
|
|
|
|
|
|
|
@return If Node is NULL or colored black.
|
|
|
|
**/
|
|
|
|
BOOLEAN
|
|
|
|
NodeIsNullOrBlack (
|
|
|
|
IN CONST RED_BLACK_TREE_NODE *Node
|
|
|
|
)
|
|
|
|
{
|
2014-08-16 18:18:59 +02:00
|
|
|
return (BOOLEAN)(Node == NULL || Node->Color == RedBlackTreeBlack);
|
MdePkg: introduce BaseOrderedCollectionRedBlackTreeLib library instance
edk2 should have a fast and easy-to-use associative array (a dictionary)
type.
Red-black trees have O(log(n)) worst case time complexity for lookup,
insertion, and deletion (where n is the number of nodes in the tree). They
support minimum and maximum lookup with the same time complexity, hence
red-black trees double as priority queues as well.
Given an iterator to a red-black tree node, getting the next or previous
node (which corresponds to the ordered successor or the predecessor,
respectively, according to the user-defined ordering) is O(log(n)) as
well.
The code reflects the Binary Search Trees and Red-Black Trees chapters of
Introduction to Algorithms, by Cormen, Leiserson, Rivest. One point where
the implementation diverges is the first phase of the Delete() operation.
During that phase, the book's algorithm copies the key and other business
*contents* of the successor node (in case the successor node is affected),
and releases the successor node (instead of the node that the user
requested to delete).
While semantically correct, this would break the above iterator validity
guarantee. This implementation replaces the copying of business contents
between nodes with suitable relinking of nodes, so that all iterators
(except the one whose deletion is being requested) remain valid.
I had written this code originally in approx. 2002. I personally own the
copyright of that version and am hereby relicensing it to Red Hat, under
the BSDL. I had used the original code in a few personal projects since,
for example in the lbzip2-0.x parallel (de)compressor, and now I've ported
the library to edk2. Both during the original implementation and now
during the porting I verified all the cases and their proofs as rigorously
as I could, on paper. (NB, I couldn't find any errors in the 2002 code
now.)
During the porting to edk2, I documented all those cases in code comments
as well (at least half of the source is documentation). These comments are
not blind copies of diagrams from the Algorithms book, nor are they copies
from my original code -- I've done them all fresh now, and I've only
matched the results against the book. Reviewers are invited to sit down
with a pen, some paper, the book, and the code.
The Validate() function verifies the internal red-black properties of the
tree. This function helps with unit testing, and is only invoked when
requested with the PcdValidateOrderedCollection feature flag.
A note about diagrams: edges represented by backslash (\) characters are
often written as "\_", ie. with a following underscore. This is because
line-trailing backslashes are processed very early in compilation (in
translation phase 2), "splicing physical source lines to form logical
source lines". Since the edk2 coding style requires "//" comments for such
documentation, a trailing backslash would splice the next physical line
into the "scope" of the comment. To prevent this, trailing backslashes are
defanged by appending underscores, which should be visually bearable.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Michael Kinney <michael.d.kinney@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15791 6f19259b-4bc3-4df7-8a09-765794883524
2014-08-12 09:29:04 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
Delete a node from the tree, unlinking the associated user structure.
|
|
|
|
|
|
|
|
Read-write operation.
|
|
|
|
|
|
|
|
@param[in,out] Tree The tree to delete Node from.
|
|
|
|
|
|
|
|
@param[in] Node The tree node to delete from Tree. The caller is
|
|
|
|
responsible for ensuring that Node belongs to
|
|
|
|
Tree, and that Node is non-NULL and valid. Node is
|
|
|
|
typically an earlier return value, or output
|
|
|
|
parameter, of:
|
|
|
|
|
|
|
|
- OrderedCollectionFind(), for deleting a node by
|
|
|
|
user structure key,
|
|
|
|
|
|
|
|
- OrderedCollectionMin() / OrderedCollectionMax(),
|
|
|
|
for deleting the minimum / maximum node,
|
|
|
|
|
|
|
|
- OrderedCollectionNext() /
|
|
|
|
OrderedCollectionPrev(), for deleting a node
|
|
|
|
found during an iteration,
|
|
|
|
|
|
|
|
- OrderedCollectionInsert() with return value
|
|
|
|
RETURN_ALREADY_STARTED, for deleting a node
|
|
|
|
whose linked user structure caused collision
|
|
|
|
during insertion.
|
|
|
|
|
|
|
|
Given a non-empty Tree, Tree->Root is also a valid
|
|
|
|
Node argument (typically used for simplicity in
|
|
|
|
loops that empty the tree completely).
|
|
|
|
|
|
|
|
Node is released with MemoryAllocationLib's
|
|
|
|
FreePool() function.
|
|
|
|
|
|
|
|
Existing RED_BLACK_TREE_NODE pointers (ie.
|
|
|
|
iterators) *different* from Node remain valid. For
|
|
|
|
example:
|
|
|
|
|
|
|
|
- OrderedCollectionNext() /
|
|
|
|
OrderedCollectionPrev() iterations in the caller
|
|
|
|
can be continued from Node, if
|
|
|
|
OrderedCollectionNext() or
|
|
|
|
OrderedCollectionPrev() is called on Node
|
|
|
|
*before* OrderedCollectionDelete() is. That is,
|
|
|
|
fetch the successor / predecessor node first,
|
|
|
|
then delete Node.
|
|
|
|
|
|
|
|
- On-going iterations in the caller that would
|
|
|
|
have otherwise returned Node at some point, as
|
|
|
|
dictated by user structure order, will correctly
|
|
|
|
reflect the absence of Node after
|
|
|
|
OrderedCollectionDelete() is called
|
|
|
|
mid-iteration.
|
|
|
|
|
|
|
|
@param[out] UserStruct If the caller provides this optional output-only
|
|
|
|
parameter, then on output it is set to the user
|
|
|
|
structure originally linked by Node (which is now
|
|
|
|
freed).
|
|
|
|
|
|
|
|
This is a convenience that may save the caller a
|
|
|
|
OrderedCollectionUserStruct() invocation before
|
|
|
|
calling OrderedCollectionDelete(), in order to
|
|
|
|
retrieve the user structure being unlinked.
|
|
|
|
**/
|
|
|
|
VOID
|
|
|
|
EFIAPI
|
|
|
|
OrderedCollectionDelete (
|
|
|
|
IN OUT RED_BLACK_TREE *Tree,
|
|
|
|
IN RED_BLACK_TREE_NODE *Node,
|
|
|
|
OUT VOID **UserStruct OPTIONAL
|
|
|
|
)
|
|
|
|
{
|
|
|
|
RED_BLACK_TREE_NODE *NewRoot;
|
2014-08-20 04:06:12 +02:00
|
|
|
RED_BLACK_TREE_NODE *OrigLeftChild;
|
|
|
|
RED_BLACK_TREE_NODE *OrigRightChild;
|
|
|
|
RED_BLACK_TREE_NODE *OrigParent;
|
|
|
|
RED_BLACK_TREE_NODE *Child;
|
|
|
|
RED_BLACK_TREE_NODE *Parent;
|
MdePkg: introduce BaseOrderedCollectionRedBlackTreeLib library instance
edk2 should have a fast and easy-to-use associative array (a dictionary)
type.
Red-black trees have O(log(n)) worst case time complexity for lookup,
insertion, and deletion (where n is the number of nodes in the tree). They
support minimum and maximum lookup with the same time complexity, hence
red-black trees double as priority queues as well.
Given an iterator to a red-black tree node, getting the next or previous
node (which corresponds to the ordered successor or the predecessor,
respectively, according to the user-defined ordering) is O(log(n)) as
well.
The code reflects the Binary Search Trees and Red-Black Trees chapters of
Introduction to Algorithms, by Cormen, Leiserson, Rivest. One point where
the implementation diverges is the first phase of the Delete() operation.
During that phase, the book's algorithm copies the key and other business
*contents* of the successor node (in case the successor node is affected),
and releases the successor node (instead of the node that the user
requested to delete).
While semantically correct, this would break the above iterator validity
guarantee. This implementation replaces the copying of business contents
between nodes with suitable relinking of nodes, so that all iterators
(except the one whose deletion is being requested) remain valid.
I had written this code originally in approx. 2002. I personally own the
copyright of that version and am hereby relicensing it to Red Hat, under
the BSDL. I had used the original code in a few personal projects since,
for example in the lbzip2-0.x parallel (de)compressor, and now I've ported
the library to edk2. Both during the original implementation and now
during the porting I verified all the cases and their proofs as rigorously
as I could, on paper. (NB, I couldn't find any errors in the 2002 code
now.)
During the porting to edk2, I documented all those cases in code comments
as well (at least half of the source is documentation). These comments are
not blind copies of diagrams from the Algorithms book, nor are they copies
from my original code -- I've done them all fresh now, and I've only
matched the results against the book. Reviewers are invited to sit down
with a pen, some paper, the book, and the code.
The Validate() function verifies the internal red-black properties of the
tree. This function helps with unit testing, and is only invoked when
requested with the PcdValidateOrderedCollection feature flag.
A note about diagrams: edges represented by backslash (\) characters are
often written as "\_", ie. with a following underscore. This is because
line-trailing backslashes are processed very early in compilation (in
translation phase 2), "splicing physical source lines to form logical
source lines". Since the edk2 coding style requires "//" comments for such
documentation, a trailing backslash would splice the next physical line
into the "scope" of the comment. To prevent this, trailing backslashes are
defanged by appending underscores, which should be visually bearable.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Michael Kinney <michael.d.kinney@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15791 6f19259b-4bc3-4df7-8a09-765794883524
2014-08-12 09:29:04 +02:00
|
|
|
RED_BLACK_TREE_COLOR ColorOfUnlinked;
|
|
|
|
|
|
|
|
NewRoot = Tree->Root;
|
|
|
|
OrigLeftChild = Node->Left,
|
|
|
|
OrigRightChild = Node->Right,
|
|
|
|
OrigParent = Node->Parent;
|
|
|
|
|
|
|
|
if (UserStruct != NULL) {
|
|
|
|
*UserStruct = Node->UserStruct;
|
|
|
|
}
|
|
|
|
|
|
|
|
//
|
|
|
|
// After this block, no matter which branch we take:
|
|
|
|
// - Child will point to the unique (or NULL) original child of the node that
|
|
|
|
// we will have unlinked,
|
|
|
|
// - Parent will point to the *position* of the original parent of the node
|
|
|
|
// that we will have unlinked.
|
|
|
|
//
|
|
|
|
if (OrigLeftChild == NULL || OrigRightChild == NULL) {
|
|
|
|
//
|
|
|
|
// Node has at most one child. We can connect that child (if any) with
|
|
|
|
// Node's parent (if any), unlinking Node. This will preserve ordering
|
|
|
|
// because the subtree rooted in Node's child (if any) remains on the same
|
|
|
|
// side of Node's parent (if any) that Node was before.
|
|
|
|
//
|
|
|
|
Parent = OrigParent;
|
|
|
|
Child = (OrigLeftChild != NULL) ? OrigLeftChild : OrigRightChild;
|
|
|
|
ColorOfUnlinked = Node->Color;
|
|
|
|
|
|
|
|
if (Child != NULL) {
|
|
|
|
Child->Parent = Parent;
|
|
|
|
}
|
|
|
|
if (OrigParent == NULL) {
|
|
|
|
NewRoot = Child;
|
|
|
|
} else {
|
|
|
|
if (Node == OrigParent->Left) {
|
|
|
|
OrigParent->Left = Child;
|
|
|
|
} else {
|
|
|
|
OrigParent->Right = Child;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
//
|
|
|
|
// Node has two children. We unlink Node's successor, and then link it into
|
|
|
|
// Node's place, keeping Node's original color. This preserves ordering
|
|
|
|
// because:
|
|
|
|
// - Node's left subtree is less than Node, hence less than Node's
|
|
|
|
// successor.
|
|
|
|
// - Node's right subtree is greater than Node. Node's successor is the
|
|
|
|
// minimum of that subtree, hence Node's successor is less than Node's
|
|
|
|
// right subtree with its minimum removed.
|
|
|
|
// - Node's successor is in Node's subtree, hence it falls on the same side
|
|
|
|
// of Node's parent as Node itself. The relinking doesn't change this
|
|
|
|
// relation.
|
|
|
|
//
|
|
|
|
RED_BLACK_TREE_NODE *ToRelink;
|
|
|
|
|
|
|
|
ToRelink = OrigRightChild;
|
|
|
|
if (ToRelink->Left == NULL) {
|
|
|
|
//
|
|
|
|
// OrigRightChild itself is Node's successor, it has no left child:
|
|
|
|
//
|
|
|
|
// OrigParent
|
|
|
|
// |
|
|
|
|
// Node: B
|
|
|
|
// / \_
|
|
|
|
// OrigLeftChild: A OrigRightChild: E <--- Parent, ToRelink
|
|
|
|
// \_
|
|
|
|
// F <--- Child
|
|
|
|
//
|
|
|
|
Parent = OrigRightChild;
|
|
|
|
Child = OrigRightChild->Right;
|
|
|
|
} else {
|
|
|
|
do {
|
|
|
|
ToRelink = ToRelink->Left;
|
|
|
|
} while (ToRelink->Left != NULL);
|
|
|
|
|
|
|
|
//
|
|
|
|
// Node's successor is the minimum of OrigRightChild's proper subtree:
|
|
|
|
//
|
|
|
|
// OrigParent
|
|
|
|
// |
|
|
|
|
// Node: B
|
|
|
|
// / \_
|
|
|
|
// OrigLeftChild: A OrigRightChild: E <--- Parent
|
|
|
|
// /
|
|
|
|
// C <--- ToRelink
|
|
|
|
// \_
|
|
|
|
// D <--- Child
|
|
|
|
Parent = ToRelink->Parent;
|
|
|
|
Child = ToRelink->Right;
|
|
|
|
|
|
|
|
//
|
|
|
|
// Unlink Node's successor (ie. ToRelink):
|
|
|
|
//
|
|
|
|
// OrigParent
|
|
|
|
// |
|
|
|
|
// Node: B
|
|
|
|
// / \_
|
|
|
|
// OrigLeftChild: A OrigRightChild: E <--- Parent
|
|
|
|
// /
|
|
|
|
// D <--- Child
|
|
|
|
//
|
|
|
|
// C <--- ToRelink
|
|
|
|
//
|
|
|
|
Parent->Left = Child;
|
2014-08-20 04:06:12 +02:00
|
|
|
if (Child != NULL) {
|
MdePkg: introduce BaseOrderedCollectionRedBlackTreeLib library instance
edk2 should have a fast and easy-to-use associative array (a dictionary)
type.
Red-black trees have O(log(n)) worst case time complexity for lookup,
insertion, and deletion (where n is the number of nodes in the tree). They
support minimum and maximum lookup with the same time complexity, hence
red-black trees double as priority queues as well.
Given an iterator to a red-black tree node, getting the next or previous
node (which corresponds to the ordered successor or the predecessor,
respectively, according to the user-defined ordering) is O(log(n)) as
well.
The code reflects the Binary Search Trees and Red-Black Trees chapters of
Introduction to Algorithms, by Cormen, Leiserson, Rivest. One point where
the implementation diverges is the first phase of the Delete() operation.
During that phase, the book's algorithm copies the key and other business
*contents* of the successor node (in case the successor node is affected),
and releases the successor node (instead of the node that the user
requested to delete).
While semantically correct, this would break the above iterator validity
guarantee. This implementation replaces the copying of business contents
between nodes with suitable relinking of nodes, so that all iterators
(except the one whose deletion is being requested) remain valid.
I had written this code originally in approx. 2002. I personally own the
copyright of that version and am hereby relicensing it to Red Hat, under
the BSDL. I had used the original code in a few personal projects since,
for example in the lbzip2-0.x parallel (de)compressor, and now I've ported
the library to edk2. Both during the original implementation and now
during the porting I verified all the cases and their proofs as rigorously
as I could, on paper. (NB, I couldn't find any errors in the 2002 code
now.)
During the porting to edk2, I documented all those cases in code comments
as well (at least half of the source is documentation). These comments are
not blind copies of diagrams from the Algorithms book, nor are they copies
from my original code -- I've done them all fresh now, and I've only
matched the results against the book. Reviewers are invited to sit down
with a pen, some paper, the book, and the code.
The Validate() function verifies the internal red-black properties of the
tree. This function helps with unit testing, and is only invoked when
requested with the PcdValidateOrderedCollection feature flag.
A note about diagrams: edges represented by backslash (\) characters are
often written as "\_", ie. with a following underscore. This is because
line-trailing backslashes are processed very early in compilation (in
translation phase 2), "splicing physical source lines to form logical
source lines". Since the edk2 coding style requires "//" comments for such
documentation, a trailing backslash would splice the next physical line
into the "scope" of the comment. To prevent this, trailing backslashes are
defanged by appending underscores, which should be visually bearable.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Michael Kinney <michael.d.kinney@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15791 6f19259b-4bc3-4df7-8a09-765794883524
2014-08-12 09:29:04 +02:00
|
|
|
Child->Parent = Parent;
|
|
|
|
}
|
|
|
|
|
|
|
|
//
|
|
|
|
// We start to link Node's unlinked successor into Node's place:
|
|
|
|
//
|
|
|
|
// OrigParent
|
|
|
|
// |
|
|
|
|
// Node: B C <--- ToRelink
|
|
|
|
// / \_
|
|
|
|
// OrigLeftChild: A OrigRightChild: E <--- Parent
|
|
|
|
// /
|
|
|
|
// D <--- Child
|
|
|
|
//
|
|
|
|
//
|
|
|
|
//
|
|
|
|
ToRelink->Right = OrigRightChild;
|
|
|
|
OrigRightChild->Parent = ToRelink;
|
|
|
|
}
|
|
|
|
|
|
|
|
//
|
|
|
|
// The rest handles both cases, attaching ToRelink (Node's original
|
|
|
|
// successor) to OrigLeftChild and OrigParent.
|
|
|
|
//
|
|
|
|
// Parent,
|
|
|
|
// OrigParent ToRelink OrigParent
|
|
|
|
// | | |
|
|
|
|
// Node: B | Node: B Parent
|
|
|
|
// v |
|
|
|
|
// OrigRightChild: E C <--- ToRelink |
|
|
|
|
// / \ / \ v
|
|
|
|
// OrigLeftChild: A F OrigLeftChild: A OrigRightChild: E
|
|
|
|
// ^ /
|
|
|
|
// | D <--- Child
|
|
|
|
// Child
|
|
|
|
//
|
|
|
|
ToRelink->Left = OrigLeftChild;
|
|
|
|
OrigLeftChild->Parent = ToRelink;
|
|
|
|
|
|
|
|
//
|
|
|
|
// Node's color must be preserved in Node's original place.
|
|
|
|
//
|
|
|
|
ColorOfUnlinked = ToRelink->Color;
|
|
|
|
ToRelink->Color = Node->Color;
|
|
|
|
|
|
|
|
//
|
|
|
|
// Finish linking Node's unlinked successor into Node's place.
|
|
|
|
//
|
|
|
|
// Parent,
|
|
|
|
// Node: B ToRelink Node: B
|
|
|
|
// |
|
|
|
|
// OrigParent | OrigParent Parent
|
|
|
|
// | v | |
|
|
|
|
// OrigRightChild: E C <--- ToRelink |
|
|
|
|
// / \ / \ v
|
|
|
|
// OrigLeftChild: A F OrigLeftChild: A OrigRightChild: E
|
|
|
|
// ^ /
|
|
|
|
// | D <--- Child
|
|
|
|
// Child
|
|
|
|
//
|
|
|
|
ToRelink->Parent = OrigParent;
|
|
|
|
if (OrigParent == NULL) {
|
|
|
|
NewRoot = ToRelink;
|
|
|
|
} else {
|
|
|
|
if (Node == OrigParent->Left) {
|
|
|
|
OrigParent->Left = ToRelink;
|
|
|
|
} else {
|
|
|
|
OrigParent->Right = ToRelink;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
FreePool (Node);
|
|
|
|
|
|
|
|
//
|
|
|
|
// If the node that we unlinked from its original spot (ie. Node itself, or
|
|
|
|
// Node's successor), was red, then we broke neither property #3 nor property
|
|
|
|
// #4: we didn't create any red-red edge between Child and Parent, and we
|
|
|
|
// didn't change the black count on any path.
|
|
|
|
//
|
|
|
|
if (ColorOfUnlinked == RedBlackTreeBlack) {
|
|
|
|
//
|
|
|
|
// However, if the unlinked node was black, then we have to transfer its
|
|
|
|
// "black-increment" to its unique child (pointed-to by Child), lest we
|
|
|
|
// break property #4 for its ancestors.
|
|
|
|
//
|
|
|
|
// If Child is red, we can simply color it black. If Child is black
|
|
|
|
// already, we can't technically transfer a black-increment to it, due to
|
|
|
|
// property #1.
|
|
|
|
//
|
|
|
|
// In the following loop we ascend searching for a red node to color black,
|
|
|
|
// or until we reach the root (in which case we can drop the
|
|
|
|
// black-increment). Inside the loop body, Child has a black value of 2,
|
|
|
|
// transitorily breaking property #1 locally, but maintaining property #4
|
|
|
|
// globally.
|
|
|
|
//
|
|
|
|
// Rotations in the loop preserve property #4.
|
|
|
|
//
|
|
|
|
while (Child != NewRoot && NodeIsNullOrBlack (Child)) {
|
2014-08-20 04:06:12 +02:00
|
|
|
RED_BLACK_TREE_NODE *Sibling;
|
|
|
|
RED_BLACK_TREE_NODE *LeftNephew;
|
|
|
|
RED_BLACK_TREE_NODE *RightNephew;
|
MdePkg: introduce BaseOrderedCollectionRedBlackTreeLib library instance
edk2 should have a fast and easy-to-use associative array (a dictionary)
type.
Red-black trees have O(log(n)) worst case time complexity for lookup,
insertion, and deletion (where n is the number of nodes in the tree). They
support minimum and maximum lookup with the same time complexity, hence
red-black trees double as priority queues as well.
Given an iterator to a red-black tree node, getting the next or previous
node (which corresponds to the ordered successor or the predecessor,
respectively, according to the user-defined ordering) is O(log(n)) as
well.
The code reflects the Binary Search Trees and Red-Black Trees chapters of
Introduction to Algorithms, by Cormen, Leiserson, Rivest. One point where
the implementation diverges is the first phase of the Delete() operation.
During that phase, the book's algorithm copies the key and other business
*contents* of the successor node (in case the successor node is affected),
and releases the successor node (instead of the node that the user
requested to delete).
While semantically correct, this would break the above iterator validity
guarantee. This implementation replaces the copying of business contents
between nodes with suitable relinking of nodes, so that all iterators
(except the one whose deletion is being requested) remain valid.
I had written this code originally in approx. 2002. I personally own the
copyright of that version and am hereby relicensing it to Red Hat, under
the BSDL. I had used the original code in a few personal projects since,
for example in the lbzip2-0.x parallel (de)compressor, and now I've ported
the library to edk2. Both during the original implementation and now
during the porting I verified all the cases and their proofs as rigorously
as I could, on paper. (NB, I couldn't find any errors in the 2002 code
now.)
During the porting to edk2, I documented all those cases in code comments
as well (at least half of the source is documentation). These comments are
not blind copies of diagrams from the Algorithms book, nor are they copies
from my original code -- I've done them all fresh now, and I've only
matched the results against the book. Reviewers are invited to sit down
with a pen, some paper, the book, and the code.
The Validate() function verifies the internal red-black properties of the
tree. This function helps with unit testing, and is only invoked when
requested with the PcdValidateOrderedCollection feature flag.
A note about diagrams: edges represented by backslash (\) characters are
often written as "\_", ie. with a following underscore. This is because
line-trailing backslashes are processed very early in compilation (in
translation phase 2), "splicing physical source lines to form logical
source lines". Since the edk2 coding style requires "//" comments for such
documentation, a trailing backslash would splice the next physical line
into the "scope" of the comment. To prevent this, trailing backslashes are
defanged by appending underscores, which should be visually bearable.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Michael Kinney <michael.d.kinney@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15791 6f19259b-4bc3-4df7-8a09-765794883524
2014-08-12 09:29:04 +02:00
|
|
|
|
|
|
|
if (Child == Parent->Left) {
|
|
|
|
Sibling = Parent->Right;
|
|
|
|
//
|
|
|
|
// Sibling can never be NULL (ie. a leaf).
|
|
|
|
//
|
|
|
|
// If Sibling was NULL, then the black count on the path from Parent to
|
|
|
|
// Sibling would equal Parent's black value, plus 1 (due to property
|
|
|
|
// #2). Whereas the black count on the path from Parent to any leaf via
|
|
|
|
// Child would be at least Parent's black value, plus 2 (due to Child's
|
|
|
|
// black value of 2). This would clash with property #4.
|
|
|
|
//
|
|
|
|
// (Sibling can be black of course, but it has to be an internal node.
|
|
|
|
// Internality allows Sibling to have children, bumping the black
|
|
|
|
// counts of paths that go through it.)
|
|
|
|
//
|
|
|
|
ASSERT (Sibling != NULL);
|
|
|
|
if (Sibling->Color == RedBlackTreeRed) {
|
|
|
|
//
|
|
|
|
// Sibling's red color implies its children (if any), node C and node
|
|
|
|
// E, are black (property #3). It also implies that Parent is black.
|
|
|
|
//
|
|
|
|
// grandparent grandparent
|
|
|
|
// | |
|
|
|
|
// Parent,b:B b:D
|
|
|
|
// / \ / \_
|
|
|
|
// Child,2b:A Sibling,r:D ---> Parent,r:B b:E
|
|
|
|
// /\ /\_
|
|
|
|
// b:C b:E Child,2b:A Sibling,b:C
|
|
|
|
//
|
|
|
|
Sibling->Color = RedBlackTreeBlack;
|
|
|
|
Parent->Color = RedBlackTreeRed;
|
|
|
|
RedBlackTreeRotateLeft (Parent, &NewRoot);
|
|
|
|
Sibling = Parent->Right;
|
|
|
|
//
|
|
|
|
// Same reasoning as above.
|
|
|
|
//
|
|
|
|
ASSERT (Sibling != NULL);
|
|
|
|
}
|
|
|
|
|
|
|
|
//
|
|
|
|
// Sibling is black, and not NULL. (Ie. Sibling is a black internal
|
|
|
|
// node.)
|
|
|
|
//
|
|
|
|
ASSERT (Sibling->Color == RedBlackTreeBlack);
|
|
|
|
LeftNephew = Sibling->Left;
|
|
|
|
RightNephew = Sibling->Right;
|
|
|
|
if (NodeIsNullOrBlack (LeftNephew) &&
|
|
|
|
NodeIsNullOrBlack (RightNephew)) {
|
|
|
|
//
|
|
|
|
// In this case we can "steal" one black value from Child and Sibling
|
|
|
|
// each, and pass it to Parent. "Stealing" means that Sibling (black
|
|
|
|
// value 1) becomes red, Child (black value 2) becomes singly-black,
|
|
|
|
// and Parent will have to be examined if it can eat the
|
|
|
|
// black-increment.
|
|
|
|
//
|
|
|
|
// Sibling is allowed to become red because both of its children are
|
|
|
|
// black (property #3).
|
|
|
|
//
|
|
|
|
// grandparent Parent
|
|
|
|
// | |
|
|
|
|
// Parent,x:B Child,x:B
|
|
|
|
// / \ / \_
|
|
|
|
// Child,2b:A Sibling,b:D ---> b:A r:D
|
|
|
|
// /\ /\_
|
|
|
|
// LeftNephew,b:C RightNephew,b:E b:C b:E
|
|
|
|
//
|
|
|
|
Sibling->Color = RedBlackTreeRed;
|
|
|
|
Child = Parent;
|
|
|
|
Parent = Parent->Parent;
|
|
|
|
//
|
|
|
|
// Continue ascending.
|
|
|
|
//
|
|
|
|
} else {
|
|
|
|
//
|
|
|
|
// At least one nephew is red.
|
|
|
|
//
|
|
|
|
if (NodeIsNullOrBlack (RightNephew)) {
|
|
|
|
//
|
|
|
|
// Since the right nephew is black, the left nephew is red. Due to
|
|
|
|
// property #3, LeftNephew has two black children, hence node E is
|
|
|
|
// black.
|
|
|
|
//
|
|
|
|
// Together with the rotation, this enables us to color node F red
|
|
|
|
// (because property #3 will be satisfied). We flip node D to black
|
|
|
|
// to maintain property #4.
|
|
|
|
//
|
|
|
|
// grandparent grandparent
|
|
|
|
// | |
|
|
|
|
// Parent,x:B Parent,x:B
|
|
|
|
// /\ /\_
|
|
|
|
// Child,2b:A Sibling,b:F ---> Child,2b:A Sibling,b:D
|
|
|
|
// /\ / \_
|
|
|
|
// LeftNephew,r:D RightNephew,b:G b:C RightNephew,r:F
|
|
|
|
// /\ /\_
|
|
|
|
// b:C b:E b:E b:G
|
|
|
|
//
|
|
|
|
LeftNephew->Color = RedBlackTreeBlack;
|
|
|
|
Sibling->Color = RedBlackTreeRed;
|
|
|
|
RedBlackTreeRotateRight (Sibling, &NewRoot);
|
|
|
|
Sibling = Parent->Right;
|
|
|
|
RightNephew = Sibling->Right;
|
|
|
|
//
|
|
|
|
// These operations ensure that...
|
|
|
|
//
|
|
|
|
}
|
|
|
|
//
|
|
|
|
// ... RightNephew is definitely red here, plus Sibling is (still)
|
|
|
|
// black and non-NULL.
|
|
|
|
//
|
|
|
|
ASSERT (RightNephew != NULL);
|
|
|
|
ASSERT (RightNephew->Color == RedBlackTreeRed);
|
|
|
|
ASSERT (Sibling != NULL);
|
|
|
|
ASSERT (Sibling->Color == RedBlackTreeBlack);
|
|
|
|
//
|
|
|
|
// In this case we can flush the extra black-increment immediately,
|
|
|
|
// restoring property #1 for Child (node A): we color RightNephew
|
|
|
|
// (node E) from red to black.
|
|
|
|
//
|
|
|
|
// In order to maintain property #4, we exchange colors between
|
|
|
|
// Parent and Sibling (nodes B and D), and rotate left around Parent
|
|
|
|
// (node B). The transformation doesn't change the black count
|
|
|
|
// increase incurred by each partial path, eg.
|
|
|
|
// - ascending from node A: 2 + x == 1 + 1 + x
|
|
|
|
// - ascending from node C: y + 1 + x == y + 1 + x
|
|
|
|
// - ascending from node E: 0 + 1 + x == 1 + x
|
|
|
|
//
|
|
|
|
// The color exchange is valid, because even if x stands for red,
|
|
|
|
// both children of node D are black after the transformation
|
|
|
|
// (preserving property #3).
|
|
|
|
//
|
|
|
|
// grandparent grandparent
|
|
|
|
// | |
|
|
|
|
// Parent,x:B x:D
|
|
|
|
// / \ / \_
|
|
|
|
// Child,2b:A Sibling,b:D ---> b:B b:E
|
|
|
|
// / \ / \_
|
|
|
|
// y:C RightNephew,r:E b:A y:C
|
|
|
|
//
|
|
|
|
//
|
|
|
|
Sibling->Color = Parent->Color;
|
|
|
|
Parent->Color = RedBlackTreeBlack;
|
|
|
|
RightNephew->Color = RedBlackTreeBlack;
|
|
|
|
RedBlackTreeRotateLeft (Parent, &NewRoot);
|
|
|
|
Child = NewRoot;
|
|
|
|
//
|
|
|
|
// This terminates the loop.
|
|
|
|
//
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
//
|
|
|
|
// Mirrors the other branch.
|
|
|
|
//
|
|
|
|
Sibling = Parent->Left;
|
|
|
|
ASSERT (Sibling != NULL);
|
|
|
|
if (Sibling->Color == RedBlackTreeRed) {
|
|
|
|
Sibling->Color = RedBlackTreeBlack;
|
|
|
|
Parent->Color = RedBlackTreeRed;
|
|
|
|
RedBlackTreeRotateRight (Parent, &NewRoot);
|
|
|
|
Sibling = Parent->Left;
|
|
|
|
ASSERT (Sibling != NULL);
|
|
|
|
}
|
|
|
|
|
|
|
|
ASSERT (Sibling->Color == RedBlackTreeBlack);
|
|
|
|
RightNephew = Sibling->Right;
|
|
|
|
LeftNephew = Sibling->Left;
|
|
|
|
if (NodeIsNullOrBlack (RightNephew) &&
|
|
|
|
NodeIsNullOrBlack (LeftNephew)) {
|
|
|
|
Sibling->Color = RedBlackTreeRed;
|
|
|
|
Child = Parent;
|
|
|
|
Parent = Parent->Parent;
|
|
|
|
} else {
|
|
|
|
if (NodeIsNullOrBlack (LeftNephew)) {
|
|
|
|
RightNephew->Color = RedBlackTreeBlack;
|
|
|
|
Sibling->Color = RedBlackTreeRed;
|
|
|
|
RedBlackTreeRotateLeft (Sibling, &NewRoot);
|
|
|
|
Sibling = Parent->Left;
|
|
|
|
LeftNephew = Sibling->Left;
|
|
|
|
}
|
|
|
|
ASSERT (LeftNephew != NULL);
|
|
|
|
ASSERT (LeftNephew->Color == RedBlackTreeRed);
|
|
|
|
ASSERT (Sibling != NULL);
|
|
|
|
ASSERT (Sibling->Color == RedBlackTreeBlack);
|
|
|
|
Sibling->Color = Parent->Color;
|
|
|
|
Parent->Color = RedBlackTreeBlack;
|
|
|
|
LeftNephew->Color = RedBlackTreeBlack;
|
|
|
|
RedBlackTreeRotateRight (Parent, &NewRoot);
|
|
|
|
Child = NewRoot;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (Child != NULL) {
|
|
|
|
Child->Color = RedBlackTreeBlack;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
Tree->Root = NewRoot;
|
|
|
|
|
|
|
|
if (FeaturePcdGet (PcdValidateOrderedCollection)) {
|
|
|
|
RedBlackTreeValidate (Tree);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
Recursively check the red-black tree properties #1 to #4 on a node.
|
|
|
|
|
|
|
|
@param[in] Node The root of the subtree to validate.
|
|
|
|
|
|
|
|
@retval The black-height of Node's parent.
|
|
|
|
**/
|
|
|
|
UINT32
|
|
|
|
RedBlackTreeRecursiveCheck (
|
|
|
|
IN CONST RED_BLACK_TREE_NODE *Node
|
|
|
|
)
|
|
|
|
{
|
2014-08-20 04:06:12 +02:00
|
|
|
UINT32 LeftHeight;
|
|
|
|
UINT32 RightHeight;
|
MdePkg: introduce BaseOrderedCollectionRedBlackTreeLib library instance
edk2 should have a fast and easy-to-use associative array (a dictionary)
type.
Red-black trees have O(log(n)) worst case time complexity for lookup,
insertion, and deletion (where n is the number of nodes in the tree). They
support minimum and maximum lookup with the same time complexity, hence
red-black trees double as priority queues as well.
Given an iterator to a red-black tree node, getting the next or previous
node (which corresponds to the ordered successor or the predecessor,
respectively, according to the user-defined ordering) is O(log(n)) as
well.
The code reflects the Binary Search Trees and Red-Black Trees chapters of
Introduction to Algorithms, by Cormen, Leiserson, Rivest. One point where
the implementation diverges is the first phase of the Delete() operation.
During that phase, the book's algorithm copies the key and other business
*contents* of the successor node (in case the successor node is affected),
and releases the successor node (instead of the node that the user
requested to delete).
While semantically correct, this would break the above iterator validity
guarantee. This implementation replaces the copying of business contents
between nodes with suitable relinking of nodes, so that all iterators
(except the one whose deletion is being requested) remain valid.
I had written this code originally in approx. 2002. I personally own the
copyright of that version and am hereby relicensing it to Red Hat, under
the BSDL. I had used the original code in a few personal projects since,
for example in the lbzip2-0.x parallel (de)compressor, and now I've ported
the library to edk2. Both during the original implementation and now
during the porting I verified all the cases and their proofs as rigorously
as I could, on paper. (NB, I couldn't find any errors in the 2002 code
now.)
During the porting to edk2, I documented all those cases in code comments
as well (at least half of the source is documentation). These comments are
not blind copies of diagrams from the Algorithms book, nor are they copies
from my original code -- I've done them all fresh now, and I've only
matched the results against the book. Reviewers are invited to sit down
with a pen, some paper, the book, and the code.
The Validate() function verifies the internal red-black properties of the
tree. This function helps with unit testing, and is only invoked when
requested with the PcdValidateOrderedCollection feature flag.
A note about diagrams: edges represented by backslash (\) characters are
often written as "\_", ie. with a following underscore. This is because
line-trailing backslashes are processed very early in compilation (in
translation phase 2), "splicing physical source lines to form logical
source lines". Since the edk2 coding style requires "//" comments for such
documentation, a trailing backslash would splice the next physical line
into the "scope" of the comment. To prevent this, trailing backslashes are
defanged by appending underscores, which should be visually bearable.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Michael Kinney <michael.d.kinney@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15791 6f19259b-4bc3-4df7-8a09-765794883524
2014-08-12 09:29:04 +02:00
|
|
|
|
|
|
|
//
|
|
|
|
// property #2
|
|
|
|
//
|
|
|
|
if (Node == NULL) {
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
//
|
|
|
|
// property #1
|
|
|
|
//
|
|
|
|
ASSERT (Node->Color == RedBlackTreeRed || Node->Color == RedBlackTreeBlack);
|
|
|
|
|
|
|
|
//
|
|
|
|
// property #3
|
|
|
|
//
|
|
|
|
if (Node->Color == RedBlackTreeRed) {
|
|
|
|
ASSERT (NodeIsNullOrBlack (Node->Left));
|
|
|
|
ASSERT (NodeIsNullOrBlack (Node->Right));
|
|
|
|
}
|
|
|
|
|
|
|
|
//
|
|
|
|
// property #4
|
|
|
|
//
|
|
|
|
LeftHeight = RedBlackTreeRecursiveCheck (Node->Left);
|
|
|
|
RightHeight = RedBlackTreeRecursiveCheck (Node->Right);
|
|
|
|
ASSERT (LeftHeight == RightHeight);
|
|
|
|
|
|
|
|
return (Node->Color == RedBlackTreeBlack) + LeftHeight;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
A slow function that asserts that the tree is a valid red-black tree, and
|
|
|
|
that it orders user structures correctly.
|
|
|
|
|
|
|
|
Read-only operation.
|
|
|
|
|
|
|
|
This function uses the stack for recursion and is not recommended for
|
|
|
|
"production use".
|
|
|
|
|
|
|
|
@param[in] Tree The tree to validate.
|
|
|
|
**/
|
|
|
|
VOID
|
|
|
|
RedBlackTreeValidate (
|
|
|
|
IN CONST RED_BLACK_TREE *Tree
|
|
|
|
)
|
|
|
|
{
|
|
|
|
UINT32 BlackHeight;
|
2014-08-20 04:06:12 +02:00
|
|
|
UINT32 ForwardCount;
|
|
|
|
UINT32 BackwardCount;
|
|
|
|
CONST RED_BLACK_TREE_NODE *Last;
|
|
|
|
CONST RED_BLACK_TREE_NODE *Node;
|
MdePkg: introduce BaseOrderedCollectionRedBlackTreeLib library instance
edk2 should have a fast and easy-to-use associative array (a dictionary)
type.
Red-black trees have O(log(n)) worst case time complexity for lookup,
insertion, and deletion (where n is the number of nodes in the tree). They
support minimum and maximum lookup with the same time complexity, hence
red-black trees double as priority queues as well.
Given an iterator to a red-black tree node, getting the next or previous
node (which corresponds to the ordered successor or the predecessor,
respectively, according to the user-defined ordering) is O(log(n)) as
well.
The code reflects the Binary Search Trees and Red-Black Trees chapters of
Introduction to Algorithms, by Cormen, Leiserson, Rivest. One point where
the implementation diverges is the first phase of the Delete() operation.
During that phase, the book's algorithm copies the key and other business
*contents* of the successor node (in case the successor node is affected),
and releases the successor node (instead of the node that the user
requested to delete).
While semantically correct, this would break the above iterator validity
guarantee. This implementation replaces the copying of business contents
between nodes with suitable relinking of nodes, so that all iterators
(except the one whose deletion is being requested) remain valid.
I had written this code originally in approx. 2002. I personally own the
copyright of that version and am hereby relicensing it to Red Hat, under
the BSDL. I had used the original code in a few personal projects since,
for example in the lbzip2-0.x parallel (de)compressor, and now I've ported
the library to edk2. Both during the original implementation and now
during the porting I verified all the cases and their proofs as rigorously
as I could, on paper. (NB, I couldn't find any errors in the 2002 code
now.)
During the porting to edk2, I documented all those cases in code comments
as well (at least half of the source is documentation). These comments are
not blind copies of diagrams from the Algorithms book, nor are they copies
from my original code -- I've done them all fresh now, and I've only
matched the results against the book. Reviewers are invited to sit down
with a pen, some paper, the book, and the code.
The Validate() function verifies the internal red-black properties of the
tree. This function helps with unit testing, and is only invoked when
requested with the PcdValidateOrderedCollection feature flag.
A note about diagrams: edges represented by backslash (\) characters are
often written as "\_", ie. with a following underscore. This is because
line-trailing backslashes are processed very early in compilation (in
translation phase 2), "splicing physical source lines to form logical
source lines". Since the edk2 coding style requires "//" comments for such
documentation, a trailing backslash would splice the next physical line
into the "scope" of the comment. To prevent this, trailing backslashes are
defanged by appending underscores, which should be visually bearable.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Michael Kinney <michael.d.kinney@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15791 6f19259b-4bc3-4df7-8a09-765794883524
2014-08-12 09:29:04 +02:00
|
|
|
|
|
|
|
DEBUG ((DEBUG_VERBOSE, "%a: Tree=%p\n", __FUNCTION__, Tree));
|
|
|
|
|
|
|
|
//
|
|
|
|
// property #5
|
|
|
|
//
|
|
|
|
ASSERT (NodeIsNullOrBlack (Tree->Root));
|
|
|
|
|
|
|
|
//
|
|
|
|
// check the other properties
|
|
|
|
//
|
|
|
|
BlackHeight = RedBlackTreeRecursiveCheck (Tree->Root) - 1;
|
|
|
|
|
|
|
|
//
|
|
|
|
// forward ordering
|
|
|
|
//
|
|
|
|
Last = OrderedCollectionMin (Tree);
|
|
|
|
ForwardCount = (Last != NULL);
|
|
|
|
for (Node = OrderedCollectionNext (Last); Node != NULL;
|
|
|
|
Node = OrderedCollectionNext (Last)) {
|
|
|
|
ASSERT (Tree->UserStructCompare (Last->UserStruct, Node->UserStruct) < 0);
|
|
|
|
Last = Node;
|
|
|
|
++ForwardCount;
|
|
|
|
}
|
|
|
|
|
|
|
|
//
|
|
|
|
// backward ordering
|
|
|
|
//
|
|
|
|
Last = OrderedCollectionMax (Tree);
|
|
|
|
BackwardCount = (Last != NULL);
|
|
|
|
for (Node = OrderedCollectionPrev (Last); Node != NULL;
|
|
|
|
Node = OrderedCollectionPrev (Last)) {
|
|
|
|
ASSERT (Tree->UserStructCompare (Last->UserStruct, Node->UserStruct) > 0);
|
|
|
|
Last = Node;
|
|
|
|
++BackwardCount;
|
|
|
|
}
|
|
|
|
|
|
|
|
ASSERT (ForwardCount == BackwardCount);
|
|
|
|
|
|
|
|
DEBUG ((DEBUG_VERBOSE, "%a: Tree=%p BlackHeight=%Ld Count=%Ld\n",
|
|
|
|
__FUNCTION__, Tree, (INT64)BlackHeight, (INT64)ForwardCount));
|
|
|
|
}
|