在缓冲池管理器中，FetchPage 和 NewPage 函数返回已经锁定的页面指针。这个锁定机制确保页面在没有任何读取和写入时不会被驱逐。为了表示页面在内存中不再需要，程序员必须手动调用 UnpinPage。

        然而，如果程序员忘记调用 UnpinPage，页面将永远不会被驱逐出缓冲池。由于缓冲池实际上只有较少的帧，这将导致更多的页面在磁盘和内存之间交换。这样不仅会影响性能，而且这个 bug 很难被发现。

        您将实现 BasicPageGuard 类，它存储指向 BufferPoolManager 和 Page 对象的指针。一个页面保护器确保一旦超出作用域，就会调用 UnpinPage 来解除锁定页面。请注意，它仍然应该提供一个供程序员手动解除锁定页面的方法。

        由于 BasicPageGuard 隐藏了底层的页面指针，它还可以提供只读/写数据的 API，这些 API 在编译时进行检查，确保正确设置 is_dirty 标志。

        在这个和后续项目中，多个线程将会读取和写入相同的页面，因此需要使用读写锁来确保数据的正确性。请注意，在 Page 类中，已经为此目的提供了相关的锁方法。类似于解除锁定页面，程序员可能会忘记在使用后解除锁定。为了解决这个问题，您将实现 ReadPageGuard 和 WritePageGuard，它们会在作用域结束时自动解除页面的锁定。

        由于在2024-fall的project1分析过了类似的，故实现这块不在赘述。说实话我个人还是更喜欢2023f版的，这个版本的对PageGuard进行拆分得恰到好处。先是给出BasicPageGuard让我们对PageGuard的作用有个具体的理解，再Basic的基础上可以进一步升级为ReadPageGuard(下面简写为RPG)和WritePageGuard(简写为WPG)。这一套流程看下来2024f版对PageGuard的拆分程度太高了，上来就要求实现RPG和WPG，理解起来的难度要大不少。

        接下来具体分析关于如何使用PageGuard。我相信很多人可能会对As和AsMut的用法有所疑惑。但无论是RPG还是WPG，其As与AsMut都是调用BasicPG的函数。我们只要理解透彻下面四个函数那对于PageGuard的使用也就是手到擒来了。

        可以发现，GetData()与As()是配套的，而GetDataMut()和AsMut()也是配套的。而且GetDataMut这个函数中，修改了is_dirty_位，这说明一旦我们选择调用AsMut，那最好是真的对page的内容进行了修改，自然也只有WPG才能调用AsMut的。

        那什么时候调用RPG与WPG的情况也就呼之欲出了。只要需要修改page时，才需要调用WPG。如果只是读取page，那调用RPG就可以了。但是！如果你懒得思考要不要修改page那直接调用WPG也不是不行，就是会多造成disk IO降低吞吐率。如果不清楚是否需要修改page，保险起见可以直接调用WPG。

 1.   auto GetData() -> const char * { return page_->GetData(); }2.  3.   template <class T>4.   auto As() -> const T * {5.     return reinterpret_cast<const T *>(GetData());6.   }7.  8.   auto GetDataMut() -> char * {9.     is_dirty_ = true;
10.     return page_->GetData();
11.   }
12.  
13.   template <class T>
14.   auto AsMut() -> T * {
15.     return reinterpret_cast<T *>(GetDataMut());
16.   }
17.  

Task #2 - Extendible Hash Table Pages

实验说明分析

哈希表头页面（Hash Table Header Page）

头页面位于基于磁盘的可扩展哈希表的第一层，并且每个哈希表只有一个头页面。它存储指向目录页面的逻辑子指针（作为页面ID）。可以将其视为一个静态的第一层目录页面。头页面具有以下字段：

请注意，尽管页面的大小是物理限制，您应该使用 max_depth_ 来确定 directory_page_ids_ 数组的上限大小。

您必须通过仅修改其头文件（src/include/storage/page/extendible_htable_header_page.h）和相应的源文件（src/storage/page/extendible_htable_header_page.cpp）来实现可扩展哈希表的头页面。

哈希表目录页面（Hash Table Directory Page）

目录页面位于基于磁盘的可扩展哈希表的第二层。每个目录页面存储指向桶页面的逻辑子指针（作为页面ID），并包含用于处理桶映射以及动态扩展和收缩目录的元数据。目录页面具有以下字段：

请注意，尽管页面的大小是物理限制，您应该使用 max_depth_ 来确定 bucket_page_ids_ 数组的上限大小。

您必须通过仅修改其头文件（src/include/storage/page/extendible_htable_directory_page.h）和相应的源文件（src/storage/page/extendible_htable_directory_page.cpp）来实现可扩展哈希表的目

录页面。

哈希表桶页面（Hash Table Bucket Page）

桶页面位于基于磁盘的可扩展哈希表的第三层。它们实际上存储键值对。桶页面具有以下字段：

请注意，尽管页面的大小是物理限制，您应该使用 max_size_ 来确定 array_ 数组的键值对的上限大小。

您必须通过仅修改其头文件（src/include/storage/page/extendible_htable_bucket_page.h）和相应的源文件（src/storage/page/extendible_htable_bucket_page.cpp）来实现可扩展哈希表的桶页面。

重要说明：

每个可扩展哈希表的头/目录/桶页面对应于通过缓冲池获取的内存页面的内容（即 data_ 部分）。每当您读取或写入页面时，必须先从缓冲池中获取页面（使用其唯一的 page_id），然后将其重新解释为相应的类型，在读取或写入后解锁该页面。我们强烈建议您利用在任务1中实现的 PageGuard API 来实现这一目标。

举例说明可扩展哈希的插入流程

接下来直接举个例子来解释可扩展哈希表的具体实现过程：

初始Global_Depth=0，每个Bucket的Local_Depth=0，Bucket的max_size_=2。假设我们需要插入0 1 2 3 4 5 6 7 8 。

咳咳，又到了展示我精湛画图功力的时候了。Show time！

①插入0，1。由于初始的Bucket空间大小足够，可以直接插入到Bucket0中。紫色笔记表示depth，左侧表示Directory，右侧表示Buckets。

③接下来插入2，发现B0已经满了，无法直接插入。

1. 所以B0先尝试local_depth++来进行桶分裂，但是由于此时local_depth已经等于global_detph了，所以loc_d自增失败，需要glo_d先自增。此时glo_d=1
2. Loc_d++，即loc_d=1，自增成功可以进行桶分裂。原桶与新桶(brother)的loc_d都是1
3. 将原Bucket的元素进行重映射，即遍历B0的所有元素，进行key&loc_depth_mask将元素分配到原桶和新桶中。

如下图。0&1=0，1&1=1。所以0依然放在原桶中，1重新放在下标为1的新桶中。

• 重新尝试插入2。通过2&global_depth_mask即10&1=0来把2放入B0中。

③插入3。通过3&global_depth_mask即11&1=1来把3放入B1中。

④插入4。4&global_depth_mask即100&1=0，发现B0已经满了，故准备进行桶分裂。

1. 所以B0先尝试local_depth++来进行桶分裂，但是由于此时local_depth已经等于global_detph了，所以loc_d自增失败，需要glo_d先自增。此时glo_d=2
2. Loc_d++，即loc_d=2，自增成功可以进行桶分裂。原桶与新桶(brother)的loc_d都是2
3. 将原Bucket的元素进行重映射，即遍历B0的所有元素，进行key&loc_depth_mask将元素分配到原桶和新桶中。

如下图。0&11=00，10&11=10。所以0依然放在原桶B0中，2重新放在下标为2的新桶B10中。

• 重新插入4。4&global_depth_mask即100&11=00，所以把4插入到B0中

⑤插入5，5& global_depth_mask即101&11=01，发现B1这个桶已经满了，准备桶分裂

1. Glo_d > loc_d，loc_d++成功，故桶B1可以直接分裂，得到新桶B11
2. 将原桶B1的元素进行重映射(key&local_depth_mask)分配到B01和B11中
3. 重新尝试插入5，5& global_depth_mask即101&11=01，插入B01成功。如果插入失败继续尝试桶分裂。

⑥插入6，6& global_depth_mask即110&11=10，成功插入到B10中

⑦插入7，7& global_depth_mask即111&11=11，成功插入到B11中

⑧插入8,8& global_depth_mask即1000&11=00，发现桶B00已经满了，尝试进行桶分裂

1. 所以B00先尝试local_depth++来进行桶分裂，但是由于此时local_depth已经等于global_detph了，所以loc_d自增失败，需要glo_d先自增。此时glo_d=3
2. Loc_d++，即loc_d=2，自增成功可以进行桶分裂。原桶与新桶(brother)的loc_d都是3
3. 将原Bucket的元素进行重映射，即遍历B0的所有元素，进行key&loc_depth_mask将元素分配到原桶和新桶中。
4. 重新尝试插入8，8& global_depth_mask即1000&111=000插入成功。如果插入失败继续尝试桶分裂。

最后可扩展哈希表如下:

其实这个例子中，应该用page_id来标记唯一的桶，为了方便理解我就直接用下标来标识每个Bucket。

通过上述例子，我们可以总结可扩展哈希表的插入流程

1. 尝试插入key。进行key&global_depth_mask从而找到对应的Bucket下标。当前Bucket不满，直接插入成功，return。如果失败进行步骤2
2. Bucket满了。
   1. 当前global_depth > local_depth，此Bucket进行local_depth++成功，可以直接进行桶分裂。进行步骤3
   2. 当前global_depth =local_depth，此Bucket进行local_depth++失败，不可以可以直接进行桶分裂。进行Global_depth++，所以此Bucket可以进行local_depth++，桶分裂成功。进行步骤3
3. 重映射。桶分裂成功后，遍历原Bucket，对其中的每个元素elem进行elem&local_depth_mask，从而将原Bucket的元素分配到原桶和新桶中。重新进行步骤1