漫谈Linux内核哈希表(1)

简介: 关于哈希表,在内核里设计两个很重要的数据结构:    哈希链表节点: 点击(此处)折叠或打开 /*Kernel Version : 3.

关于哈希表,在内核里设计两个很重要的数据结构:
   
哈希链表节点

点击(此处)折叠或打开

  1. /*Kernel Version : 3.4.x [include/linux/types.h]*/
  2. struct hlist_node {
  3.     struct hlist_node *next, **pprev;
  4. };
    可以看到哈希节点和内核普通双向链表的节点唯一的区别就在于,前向节点 pprev 是个两级指针,至于为什么这样设计而不采用 struct list_head{} 来作为哈希链表的节点,我们后面会详细介绍。另外一个重要的数据结构是,哈希链表的表头。

   
哈希链表 表头

点击(此处)折叠或打开

  1. /*Kernel Version : 3.4.x [include/linux/types.h]*/
  2. struct hlist_head {
  3.     struct hlist_node *first;
  4. };
    因为哈希链表并不需要 双向循环 的技能,它一般适用于单向散列的场景。所以,为了减少开销,并没有用 struct hlist_node{} 来代表哈希表头,而是重新设计 struct hlist_head{} 这个数据结构。此时,一个哈希表头就只需要 4Byte 了,相比于 struct hlist_node{} 来说,存储空间已经减少了一半。这样一来,在需要大量用到哈希链表的场景,其存储空间的节约是非常明显的,特别是在嵌入式设备领域。


   接下来
,我们来重点回答一下哈希节点里那个两级指针的问题。先讲个小插曲,记得本人当年刚参加工作时,导师给安排了一个活儿,那时候年轻气盛、血气方刚,没一会儿功夫,三下五除二就搞定了。然后拿着自己的“杰作”去师傅看,师傅瞄了一眼说,你这函数简直是一坨shi(和乔老爷当年骂另外一个程序员的用词、语气差不多),谁让你函数入参传个三级指针进去的?这段代码TM能维护么?谁看得懂?完了之后感觉自己还受了莫大的委屈一样,不过谁的人生没有那么点波澜壮阔的过往呢,就像有句名言说的:程序写出来是给人看的,顺带能在机器上运行。OK,那这个故事跟我们要介绍的哈希节点的关系在哪儿呢?没错,就是struct hlist_node{}里那个前向的两级指针的存在意义。

    关于两级指针的目的与意义,让
我们采用反证法来看看,如果struct hlist_node{}被设计成如下一级指针的样子,会发生什么:

点击(此处)折叠或打开

  1. struct hlist_node {
  2.     struct hlist_node *next, *pprev;
  3. };
    假如我们现在已经有一个哈希链表了myhlist(先别管这个链表是怎么来的),链表里有4个节点node1~node4:

    
   然后就有以下两个问题跟着冒出来:
   
1)、在往哈希链myhlist里插入node1时必须这么写:

点击(此处)折叠或打开

  1. mylist.first = node1;
  2. node1->pprev=( struct hlist_node*)&mylist;
   除此之外,在插入 node2~node4 以及后续其他节点时 ( 假如按顺序插入的话 ) ,写法如下(X>=2

点击(此处)折叠或打开

  1. node[X]->next = node[X+1];
  2. node[X]->pprev = node[X-1];

简而言之啥意思呢?往哈希链表里插入元素时,如果在表头的第一个位置上插入元素,和插入在哈希链表的其他位置上的代码处理逻辑是不一样的。因为哈希表头是list_head类型,而其他节点都是list_node类型。

   2
)、同样,如果删除节点时,对于非首节点,以node2为例:

点击(此处)折叠或打开

  1. node2->pprev->next = node2->next;
  2. node2->next->pprev = node2->pprev;
    如果要删除首节点 node1 呢,则写法如下:

点击(此处)折叠或打开

  1. ((struct hlist_head*)(node1->pprev))->first = node1->next;
  2. node1->next->pprev = ( struct hlist_node*)&mylist或者 node1->next->pprev = node1->pprev;
    很明显,内核开发者们怎么会容许这样的代码存在,而且还要充分考虑效率的问题。那么,当 hlist_node.pprev 被设计成两级指针后有啥好处?
    还是以删除节点为例,如果要删除首节点,因为node1->pprev里保存的是myhlist的地址,而myhlist.first永远都指向哈希链表的第一个节点,我们要间接改变表头里的hlist_node类型的first指针的值,能想到的最直接的办法当然是二级指针,这是两级指针的宿命所决定的,为了间接改变一级指针所指的内存地址的场景。这样一来,node节点里的pprev其实指向的是其前一个节点里的第一个指针元素的地址。对于hlist_head来说,它里面只有一个指针元素,就是first指针;而对于hlist_node来说,第一个指针元素就是next。具体如下所示:

所以,记住,当我们在代码中看到类似与*(hlist_node->pprev)这样的代码时,我们心里应该清楚,此时正在哈希表里操作当前节点前一个节点里的第一个指针元素所指向的内存地址,只是以间接的方式实现罢了。那么回到删除哈希链表节点的场景,当删除首节点时,此时情况就变成了:

点击(此处)折叠或打开

  1. *(node1->pprev) = node1->next;
  2. node1->next->pprev = node1->pprev;
    删除非首节点的情况也一样:

点击(此处)折叠或打开

  1. *(node2->pprev) = node2->next;
  2. node2->next->pprev = node2->pprev;
    这样一来,我们对hlist_node里的谅解指针pprev的存在价值与意义应该很明白了,以后不至于再被眼花缭乱的取地址操作符给弄晕了。OK,扯了这么多,让我们看看内核是如何实现删除哈希链表里的节点的__hlist_del():
   
   
大家自行将上述函数里的入参n换成node2,最终和我们上面推断的结果是一致的:
   
    在标准的哈希链表里,因为最后一个节点的 next=NULL ,所以在执行第二句有效代码前首先要对当前节点的 next 值进行判断才行。
    内核提供了 hlist_add_head() ,用于实现向哈希链表里插入节点:

点击(此处)折叠或打开

  1. hlist_add_head(struct hlist_node *n, struct hlist_head *h)
    其中n表示待插入的节点,h表示哈希链表表头。在刚初始化完哈希表myhlist的情况下,依次调用四次hlist_add_head(),每次调用后myhlist哈希表的情况如下:
    ( 备注:双箭头表示两级指针,单箭头表示一级指针 )
   
理论上说,内核应该再提供一个对称的方法hlist_add_tail()才算完美,用于将哈希链表操作成如下的样子:


   还有
hlist_add_behind()hlist_add_before(),在3.17版本之前hlist_add_behind()的名字还是hlist_add_after(),不过作用都一样。两个函数原型分别如下:

点击(此处)折叠或打开

  1. hlist_add_before(struct hlist_node *n,struct hlist_node *next);
  2. hlist_add_behind(struct hlist_node *n,struct hlist_node *prev);
    其中 n 是待插入的节点, next 或者 prev 都是 n 的相对位置参考节点,其作用分别是:
   
hlist_add_before() :在 next 节点的 前面 插入 n 节点;
 
hlist_add_behind():在prev节点的 后面 插入n节点;

    接下来, 让我们…..

    1) 、在 node4 节点的 前面 插入 node3
    注意 hlist_add_before() 有个约束条件,那就是 next!=NULL。

   
2) 、在 node1 的节点 后面 插入 node5
    同样的约束条件也适用于hlist_add_behind(),即prev!=NULL
   未完,待续...
目录
相关文章
|
9天前
|
算法 Linux 调度
深入理解Linux内核调度器:从基础到优化####
本文旨在通过剖析Linux操作系统的心脏——内核调度器,为读者揭开其高效管理CPU资源的神秘面纱。不同于传统的摘要概述,本文将直接以一段精简代码片段作为引子,展示一个简化版的任务调度逻辑,随后逐步深入,详细探讨Linux内核调度器的工作原理、关键数据结构、调度算法演变以及性能调优策略,旨在为开发者与系统管理员提供一份实用的技术指南。 ####
41 4
|
13天前
|
缓存 算法 Linux
深入理解Linux内核调度器:公平性与性能的平衡####
真知灼见 本文将带你深入了解Linux操作系统的核心组件之一——完全公平调度器(CFS),通过剖析其设计原理、工作机制以及在实际系统中的应用效果,揭示它是如何在众多进程间实现资源分配的公平性与高效性的。不同于传统的摘要概述,本文旨在通过直观且富有洞察力的视角,让读者仿佛亲身体验到CFS在复杂系统环境中游刃有余地进行任务调度的过程。 ####
33 6
|
3天前
|
算法 Linux 开发者
Linux内核中的锁机制:保障并发控制的艺术####
本文深入探讨了Linux操作系统内核中实现的多种锁机制,包括自旋锁、互斥锁、读写锁等,旨在揭示这些同步原语如何高效地解决资源竞争问题,保证系统的稳定性和性能。通过分析不同锁机制的工作原理及应用场景,本文为开发者提供了在高并发环境下进行有效并发控制的实用指南。 ####
|
11天前
|
缓存 资源调度 安全
深入探索Linux操作系统的心脏——内核配置与优化####
本文作为一篇技术性深度解析文章,旨在引领读者踏上一场揭秘Linux内核配置与优化的奇妙之旅。不同于传统的摘要概述,本文将以实战为导向,直接跳入核心内容,探讨如何通过精细调整内核参数来提升系统性能、增强安全性及实现资源高效利用。从基础概念到高级技巧,逐步揭示那些隐藏在命令行背后的强大功能,为系统管理员和高级用户打开一扇通往极致性能与定制化体验的大门。 --- ###
38 9
|
10天前
|
缓存 负载均衡 Linux
深入理解Linux内核调度器
本文探讨了Linux操作系统核心组件之一——内核调度器的工作原理和设计哲学。不同于常规的技术文章,本摘要旨在提供一种全新的视角来审视Linux内核的调度机制,通过分析其对系统性能的影响以及在多核处理器环境下的表现,揭示调度器如何平衡公平性和效率。文章进一步讨论了完全公平调度器(CFS)的设计细节,包括它如何处理不同优先级的任务、如何进行负载均衡以及它是如何适应现代多核架构的挑战。此外,本文还简要概述了Linux调度器的未来发展方向,包括对实时任务支持的改进和对异构计算环境的适应性。
31 6
|
11天前
|
缓存 Linux 开发者
Linux内核中的并发控制机制:深入理解与应用####
【10月更文挑战第21天】 本文旨在为读者提供一个全面的指南,探讨Linux操作系统中用于实现多线程和进程间同步的关键技术——并发控制机制。通过剖析互斥锁、自旋锁、读写锁等核心概念及其在实际场景中的应用,本文将帮助开发者更好地理解和运用这些工具来构建高效且稳定的应用程序。 ####
30 5
|
11天前
|
算法 Unix Linux
深入理解Linux内核调度器:原理与优化
本文探讨了Linux操作系统的心脏——内核调度器(Scheduler)的工作原理,以及如何通过参数调整和代码优化来提高系统性能。不同于常规摘要仅概述内容,本摘要旨在激发读者对Linux内核调度机制深层次运作的兴趣,并简要介绍文章将覆盖的关键话题,如调度算法、实时性增强及节能策略等。
|
12天前
|
存储 监控 安全
Linux内核调优的艺术:从基础到高级###
本文深入探讨了Linux操作系统的心脏——内核的调优方法。文章首先概述了Linux内核的基本结构与工作原理,随后详细阐述了内核调优的重要性及基本原则。通过具体的参数调整示例(如sysctl、/proc/sys目录中的设置),文章展示了如何根据实际应用场景优化系统性能,包括提升CPU利用率、内存管理效率以及I/O性能等关键方面。最后,介绍了一些高级工具和技术,如perf、eBPF和SystemTap,用于更深层次的性能分析和问题定位。本文旨在为系统管理员和高级用户提供实用的内核调优策略,以最大化Linux系统的效率和稳定性。 ###
|
11天前
|
Java Linux Android开发
深入探索Android系统架构:从Linux内核到应用层
本文将带领读者深入了解Android操作系统的复杂架构,从其基于Linux的内核到丰富多彩的应用层。我们将探讨Android的各个关键组件,包括硬件抽象层(HAL)、运行时环境、以及核心库等,揭示它们如何协同工作以支持广泛的设备和应用。通过本文,您将对Android系统的工作原理有一个全面的认识,理解其如何平衡开放性与安全性,以及如何在多样化的设备上提供一致的用户体验。
|
14天前
|
Linux 数据库
Linux内核中的锁机制:保障并发操作的数据一致性####
【10月更文挑战第29天】 在多线程编程中,确保数据一致性和防止竞争条件是至关重要的。本文将深入探讨Linux操作系统中实现的几种关键锁机制,包括自旋锁、互斥锁和读写锁等。通过分析这些锁的设计原理和使用场景,帮助读者理解如何在实际应用中选择合适的锁机制以优化系统性能和稳定性。 ####
31 6