回复了主题帖： 汽车电子硬件设计

讲的什么内容呢。

回复了主题帖： >>征集 | 晒电机控制痛点与难题，一起寻求最优解！

本帖最后由 meiyao 于 2025-2-22 09:22 编辑 技术层面的痛点和难点   系统建模： 电机控制系统需要进行精确的建模，目地是进行仿真和控制算法的设计，方便后面进行产品实际进行时避免出现重大的设计失误，所以是一定要建模。 建模的难点在于需要考虑到电机的物理特性、控制电路的特性、传感器的精度等多个因素，需要有一定的经验，而且还要对电机的各方面的特性需要非常的熟悉，还需要对系统进行多维度的建模，以便准确地预测系统的行为。   控制算法设计： 电机控制系统需要设计出适用于特定应用场景的控制算法，不同一应用场景所需求的控制是不一样的，有的地方需要快，稳定，有的地方需要慢，所以要根据算法来控制。 算法设计的难点在于需要综合考虑系统的特性、控制要求以及实际应用环境等多个因素，同时需要对算法进行多层次的优化和测试，以确保算法的稳定性和可靠性，时实性，安全性。   硬件设计： 电机控制系统的硬件设计需要考虑到电路的复杂性、功率损耗、EMI等多个因素，特别是可靠性和稳定性。 硬件设计的难点在于需要在保证硬件可靠性和稳定性的同时，尽可能降低功率损耗和减少EMI，以确保系统的长期运行。 硬件设计还需要对LAYOUT也需要非常的熟悉，并且相关的LAYOUT也需要一定的设计经验和水平。   调试和测试： 电机控制系统的调试和测试需要进行多个环节的验证，包括模拟仿真、实验测试、系统集成，失效性测试，可靠性测试，高低温环境，粉层测试等。 调试和测试的难点在于需要投入大量的时间和精力，以确保系统的稳定性和性能。   电机控制的精度： 电机控制需精确地控制电机的转速和扭矩，这需要高精度的控制技术支撑。   电机效率和能量损耗： 电机在工作过程中会产生发热和能量损耗，特别是在高温环境和重负载工作时效率会大幅下降。   系统稳定性： 电机作为生产中最为核心的部分之一，需要与其他设备进行高效的协同工作，因此系统稳定性至关重要。   成本控制方面的痛点 尽管高性能的电机控制系统可以带来诸多好处，但高昂的成本往往是阻碍其广泛应用的一个重要因素。如何在保证性能的同时降低系统成本，是设计者需要考虑的关键问题。   适应性与灵活性方面的难点 不同的应用场景对电机控制的需求差异很大，一个理想的控制系统应该具备良好的适应性和灵活性，能够根据具体的应用环境做出相应的调整。这要求设计者在设计过程中充分考虑到系统的可扩展性和可配置性。

发表了主题帖： 《奔跑吧Linux内核2：调试与案例分析》+ARM64解决宕机难题

本帖最后由 meiyao 于 2025-2-17 15:40 编辑 基于ARM64解决宕机难题涉及多个方面，包括硬件、操作系统、驱动程序、应用软件等。     选择合适的硬件和操作系统： 硬件方面，尽管树莓派3B+采用ARM64架构，但其性能和内存可能不足以支持Kdump服务的所有需求。可能需要寻找一个性能更强、内存更大的ARM64设备，某些开发板或服务器级的ARM64设备。 操作系统方面，确保选择的Linux发行版支持ARM64架构，并且包含Kdump服务的必要组件。Ubuntu、Fedora等主流发行版通常都提供对ARM64的支持。 配置Kdump服务： 在ARM64平台上配置Kdump服务与在x86平台上类似，但可能需要注意一些与架构相关的细节。可能需要为Kdump内核指定正确的内存区域，并确保有足够的内存用于捕获内核崩溃信息。 编辑GRUB配置文件，为Kdump内核分配内存（使用crashkernel参数）。这通常需要在/etc/default/grub文件中进行设置，并更新GRUB配置。 编译和安装Kdump内核： 在ARM64平台上，可能需要自己编译Kdump内核，因为不是所有的Linux发行版都提供预编译的Kdump内核镜像。你可以从Linux内核源代码树中编译出适用于你的ARM64设备的Kdump内核。 测试Kdump功能： 一旦Kdump服务配置完成，可以通过触发一个内核错误（使用echo c > /proc/sysrq-trigger命令）来测试Kdump功能。这将导致系统崩溃并进入Kdump内核，然后捕获内核崩溃信息。 分析和调试： 在捕获到内核崩溃信息后，可以使用gdb或其他调试工具来分析转储文件，以确定导致崩溃的原因。 注意兼容性和限制： 由于ARM64架构与x86架构的差异，某些Kdump功能或工具可能在ARM64平台上不可用或表现不同。在搭建和测试Kdump实验环境时，要特别注意兼容性和限制。     实验目标 在QEMU虚拟机中搭建Debian实验平台，并配置Kdump服务以捕获内核崩溃信息。   实验环境 主机CPU：Intel处理器 主机内存：8GB 主机操作系统：Ubuntu Linux 20.04.1 QEMU版本：4.2.0 内核版本：Linux 5.0（Debian虚拟机中） 实验步骤 搭建QEMU虚拟机+Debian实验平台 安装QEMU虚拟机软件。 创建并配置Debian虚拟机，指定内核版本为Linux 5.0。 启动Debian虚拟机，完成系统安装和基本配置。 配置Kdump服务 在Debian虚拟机中，安装Kdump服务所需的软件包（kdump-tools、kexec-tools等）。 编辑/etc/default/grub文件，添加或修改以下参数以启用Kdump：       启动Crash工具： 需要启动Crash工具并加载内核转储文件和相应的vmlinux文件（未压缩的内核镜像）。 crash /path/to/vmlinux /path/to/vmcore  /path/to/vmlinux 是内核源码编译后生成的vmlinux文件，而 /path/to/vmcore 是内核崩溃时生成的内存转储文件。   加载内核模块符号： 如果崩溃与某个内核模块相关，可能需要加载该模块的符号信息以便更好地分析。使用 mod 命令（不带 -s 选项，除非您的Crash版本要求）： crash> mod /home/benshushu/crash/crash_lab_arm64/01_oops/oops.ko 这将加载 oops.ko 模块的符号信息。   查看内核函数调用关系： 使用 bt 命令（backtrace的缩写）来查看导致崩溃的内核函数调用关系。这可以帮助定位问题发生的代码位置： crash> bt 分析调用堆栈： 仔细查看调用堆栈中的函数名和地址，尝试理解它们之间的关系以及可能导致崩溃的原因。可能需要查阅内核源码或相关文档来更好地理解这些函数。 其他命令： Crash工具提供了许多其他有用的命令来帮助分析崩溃，比如 vm（查看内存）、ps（列出进程）、lsmod（列出加载的内核模块）等。   整理一下要点： 基于ARM64解决宕机难题确实涉及多个方面，包括硬件、操作系统、驱动程序以及应用软件等。以下是在QEMU虚拟机中搭建Debian实验平台，并配置Kdump服务以捕获内核崩溃信息的详细步骤和分析：   一、实验环境与准备 主机配置： CPU：Intel处理器 内存：8GB 操作系统：Ubuntu Linux 20.04.1 QEMU虚拟机： QEMU版本：4.2.0 内核版本：Linux 5.0（用于Debian虚拟机） 二、搭建QEMU虚拟机+Debian实验平台 安装QEMU虚拟机软件： 在Ubuntu主机中，通过APT包管理器安装QEMU及其相关依赖。   创建并配置Debian虚拟机： 使用QEMU工具创建一个新的虚拟机，并指定使用Linux 5.0内核版本。完成虚拟机的系统安装和基本配置。   启动Debian虚拟机： 确保虚拟机能够正常启动，并登录到Debian系统。   三、配置Kdump服务 安装Kdump服务所需的软件包： 在Debian虚拟机中，通过APT包管理器安装kdump-tools、kexec-tools等必要的软件包。   编辑GRUB配置文件： 编辑/etc/default/grub文件，添加或修改以下参数以启用Kdump： GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=512M" 这里，crashkernel=512M参数用于为Kdump内核分配512MB的内存。更新GRUB配置并重启虚拟机。   编译和安装Kdump内核（如必要）： 由于不是所有Linux发行版都提供预编译的Kdump内核镜像，可能需要从Linux内核源代码树中编译出适用于ARM64设备的Kdump内核。但在此实验中，由于使用的是Debian虚拟机，且已安装了必要的kdump-tools和kexec-tools软件包，通常不需要手动编译内核。   四、测试Kdump功能 触发内核错误： 在Debian虚拟机中，通过执行以下命令来触发一个内核错误： echo c > /proc/sysrq-trigger 这将导致系统崩溃并进入Kdump内核。   检查内核崩溃信息： 系统崩溃后，Kdump服务将捕获内核崩溃信息，并将其保存在指定的目录中（如/var/crash/）。检查该目录以确认内核崩溃信息已成功捕获。   五、分析和调试 启动Crash工具： 使用Crash工具加载内核转储文件和相应的vmlinux文件。例如： crash /path/to/vmlinux /path/to/vmcore 加载内核模块符号： 如果崩溃与某个内核模块相关，使用Crash工具的mod命令加载该模块的符号信息。   查看内核函数调用关系： 使用bt命令查看导致崩溃的内核函数调用关系。这有助于定位问题发生的代码位置。   分析调用堆栈： 仔细查看调用堆栈中的函数名和地址，尝试理解它们之间的关系以及可能导致崩溃的原因。可能需要查阅内核源码或相关文档来更好地理解这些函数。   使用其他Crash工具命令： Crash工具提供了许多其他有用的命令来帮助分析崩溃，如vm（查看内存）、ps（列出进程）、lsmod（列出加载的内核模块）等。根据需要选择合适的命令进行分析。

发表了主题帖： 《奔跑吧Linux内核2：调试与案例分析》+系统安全漏洞

安全漏洞分析 CPU熔断漏洞 描述：CPU熔断漏洞是一种严重的安全漏洞，它允许攻击者绕过操作系统的安全机制，获取敏感信息或执行恶意代码。 分析：书中详细分析了熔断漏洞的攻击原理，包括攻击者如何利用高性能处理器的一些副作用进行高速缓存侧信道攻击。 修复方案：书中介绍了使用KPTI（Kernel Page Table Isolation）技术来修复熔断漏洞的方法。KPTI技术通过隔离内核页表和用户页表，防止攻击者利用漏洞获取内核地址空间的信息。  CPU“幽灵”漏洞 描述：CPU“幽灵”漏洞与熔断漏洞类似，也是利用高性能处理器的一些副作用进行高速缓存侧信道攻击。它有两个变体：变体1是绕过边界检查漏洞，变体2是分支预测注入漏洞。 分析：书中重点介绍了变体1的攻击原理，包括攻击者如何利用漏洞绕过边界检查，执行恶意代码。 Linux内核的解决方案：书中也介绍了Linux内核针对“幽灵”漏洞的解决方案，这些方案旨在防止攻击者利用漏洞进行攻击。   其他安全漏洞及修复 除了上述两个漏洞外，书中还可能涉及其他Linux内核的安全漏洞及修复方法。这些漏洞可能涉及不同的子系统和组件，netfilter等。书中会分析这些漏洞的产生原理，并提供相应的修复方案。     侧信道攻击概述 侧信道攻击是一种密码学攻击技术，它利用加密设备在运行过程中泄露的侧信道信息（时间消耗、功率消耗、电磁辐射等）来攻击加密设备。这种攻击的有效性通常远高于传统的密码分析数学方法，对密码设备构成了严重威胁。   高速缓存侧信道攻击 在高速缓存侧信道攻击中，攻击者利用处理器访问不同级别内存设备时的延迟差异来获取信息。现代处理器为了提高性能，通常设置了多级高速缓存（L1、L2、L3等），其中L1高速缓存最靠近处理器核心，访问速度最快，但容量最小。随着缓存级别的提升，访问速度逐渐降低，但容量逐渐增加。   当CPU需要访问内存中的数据时，如果数据已经被缓存到高速缓存中，那么CPU将能够更快地读取数据；否则，CPU将需要从物理内存中读取数据，这将花费更长的时间。攻击者可以利用这种时间差异来推断内存中的数据。   熔断漏洞与幽灵漏洞 熔断漏洞（Meltdown）和幽灵漏洞（Spectre）是利用高速缓存侧信道攻击的典型案例。这两种漏洞都允许攻击者绕过操作系统的安全机制，获取敏感信息。   熔断漏洞：它利用处理器乱序执行和特权级数据泄露的漏洞，允许攻击者读取内核内存中的数据，即使这些数据对攻击者来说是不可访问的。 幽灵漏洞：它利用处理器的分支预测机制来执行不可见的间接跳转或调用，从而绕过正常的内存访问控制。攻击者可以利用这种机制来读取敏感数据或执行恶意代码。 高速缓存侧信道攻击伪代码解释 提供的伪代码展示了如何实现高速缓存侧信道攻击来破解被攻击内存地址中的数据。以下是伪代码的逐行解释：   定义一个信号和回调函数，当程序访问非法地址时，执行该回调函数而不是让进程因段错误而退出。 定义一个攻击者可以安全访问的数组user_probe。 把user_probe数组对应的高速缓存全部冲刷掉，以确保后续访问时能够准确测量时间。 attacked_mem_addr是攻击者没有访问权限的地址。当攻击者尝试访问时，CPU会触发异常。 判断被攻击内存地址中数据的第0位是0还是1，并根据结果计算index。 根据index的值，将user_probe数组中对应位置的数据加载到高速缓存行中。     高速缓存侧信道攻击中破解数据的过程     总结： 高速缓存侧信道攻击是一种利用处理器访问内存时的延迟差异来获取信息的攻击方式。在攻击过程中，攻击者首先定义一个可安全访问的数组user_probe，并将其对应的高速缓存冲刷干净。接着，攻击者尝试访问一个无权访问的内存地址attacked_mem_addr，此举会触发CPU异常。通过巧妙设计，攻击者能在异常发生前，利用处理器乱序执行的特点，推测出attacked_mem_addr中数据的某一位。   具体地，攻击者根据推测的位数计算出一个索引index，然后将user_probe数组中对应位置的数据加载到高速缓存行。随后，通过遍历user_probe数组并测量访问时间，攻击者能判断数据是否已被缓存，从而推断出attacked_mem_addr中数据的具体位。这一过程可重复进行，直至破解出完整数据。   熔断漏洞和幽灵漏洞便是此类攻击的典型案例，它们严重威胁了系统的安全性。为防止此类攻击，需采取诸如KPTI技术等安全措施，以隔离内核页表和用户页表，保护内核地址空间的信息不被泄露。

发表了主题帖： 《奔跑吧Linux内核2：调试与案例分析》+内核系列方面知识、内核调试与性能优化

Linux内核调试与性能优化 Linux作为一个开源的操作系统，被广泛应用于各种场景。对于Linux内核的开发者和系统管理员来说，掌握内核调试和性能优化的技巧是至关重要的。    内核开发和驱动编写是一项复杂且需要高度精确性的任务。为了确保代码的稳定性和安全性，开发者需要掌握一系列调试技巧和工具。常用的内核调试工具和方法，以及如何在QEMU虚拟机+Debian平台上进行实验的设置。 其中包括, 内存检测和死锁检测 内存检测,使用工具sparse或内核自带的内存调试选项来检测内存越界访问、内存泄漏等问题。 死锁检测,内核中的死锁可以通过锁调试选项、静态代码分析工具和动态跟踪工具来检测。确保所有锁的使用都遵循一致的规则，避免循环依赖。 内核调试小技巧 使用printk,printk是内核中最基本的调试输出函数。合理使用printk可以帮助开发者理解代码的执行流程。 启用内核调试选项,编译内核时启用调试选项，CONFIG_DEBUG_KERNEL、CONFIG_DEBUG_FS等，可以提供更多的调试信息和文件系统支持。 利用QEMU的调试功能,QEMU提供了GDB远程调试功能，允许开发者在虚拟机中运行内核时，通过GDB进行源码级调试。   打造 ARM64 实验平台及内核编译优化等级说明   打造 ARM64 实验平台 市面上存在多种基于 ARM64 架构的开发板，树莓派等，这些开发板是学习 ARM64 架构的绝佳工具。除了硬件开发板，还可以利用 QEMU 虚拟机来模拟 ARM64 处理器，这具有以下两大优势： 无需额外购买硬件,只需一台安装了 Linux 发行版的计算机即可。 支持单步调试内核,QEMU 提供的这一功能对于内核开发者来说尤为重要。 在本章中，将使用 QEMU 来搭建 ARM64 实验平台，并介绍如何构建两种文件系统：一种是使用 BusyBox 打造的简单文件系统，另一种是使用 Debian 根文件系统打造的实用文件系统。   关闭 QEMU 虚拟机的方法： 在 Linux 主机的另一个终端中输入 killall qemu-system-aarch64 命令。 或者使用 Ctrl+A 组合键，然后按 X 键来关闭 QEMU 虚拟机。     使用“O0”优化等级编译内核 GCC 编译器提供了多个优化等级，这些等级对代码的执行效率和调试体验有直接影响。以下是对这些优化等级的简要说明： “O0”：关闭所有优化。这通常用于调试，因为优化可能会改变代码的结构，使得调试变得困难。然而，关闭优化可能会导致代码执行效率降低。 “O1”：最基本的优化等级。它会进行一些简单的优化，但不会改变代码的结构，因此调试体验相对较好。 “O2”：从“O1”进阶的优化等级，也是很多软件默认使用的优化等级。它会对代码进行更深入的优化，以提高执行效率。但这也可能导致调试变得更加困难，因为优化可能会改变代码的执行路径和变量布局。   死锁检测：   死锁概述 死锁是指两个或多个进程（或线程）在相互等待对方持有的资源，从而导致它们都无法继续执行的状态。在内核开发中，由于并发设计的复杂性，即使采用正确的编程思路，死锁也可能发生。   Linux内核中的死锁类型 递归死锁：这通常发生在中断处理或其他延迟操作中，当这些操作试图获取与它们外部代码已经持有的锁相同的锁时。 AB-BA死锁：这是最常见的死锁类型之一。它发生在两个或多个进程（或线程）分别持有对方需要的锁，并且以不同的顺序请求这些锁时。进程A持有锁A并请求锁B，而进程B持有锁B并请求锁A，这将导致死锁。 Lockdep模块 Linux内核在2006年引入了Lockdep模块，这是一个用于检测和预防死锁的工具。Lockdep通过跟踪每个锁的持有状态和锁之间的依赖关系，来确保锁的使用是正确的。   AB-BA死锁示例 下面是一个简化的AB-BA死锁示例，虽然这个示例不是直接在Linux内核环境中编写的，但它展示了AB-BA死锁的基本原理。请注意，在真实的内核模块中，你需要使用内核提供的锁机制（自旋锁、互斥锁等）和Lockdep API。 // 假设的AB-BA死锁示例（非内核代码） #include <stdio.h> #include <pthread.h> #include <unistd.h> pthread_mutex_t lockA = PTHREAD_MUTEX_INITIALIZER; pthread_mutex_t lockB = PTHREAD_MUTEX_INITIALIZER; void* thread1_func(void* arg) { pthread_mutex_lock(&lockA); sleep(1); // 模拟一些工作 pthread_mutex_lock(&lockB); // 这里可能会死锁，如果thread2已经持有lockB并请求lockA // ... 执行一些操作 pthread_mutex_unlock(&lockB); pthread_mutex_unlock(&lockA); return NULL; } void* thread2_func(void* arg) { pthread_mutex_lock(&lockB); sleep(1); // 模拟一些工作 pthread_mutex_lock(&lockA); // 这里可能会死锁，如果thread1已经持有lockA并请求lockB // ... 执行一些操作 pthread_mutex_unlock(&lockA); pthread_mutex_unlock(&lockB); return NULL; } int main() { pthread_t thread1, thread2; pthread_create(&thread1, NULL, thread1_func, NULL); pthread_create(&thread2, NULL, thread2_func, NULL); pthread_join(thread1, NULL); pthread_join(thread2, NULL); return 0; }   在Linux内核开发中，printk是一个非常受欢迎的调试工具。下面将详细解释printk函数及其与C库提供的printf函数的区别，并介绍如何使用printk进行内核调试。 动态输出     数据类型与格式化输出 在内核开发中，经常会遇到各种数据类型， long long、unsigned long long、size_t、ssize_t 等。 为了正确地输出这些类型的数据，需要使用相应的格式化字符串： %llu 用于输出 unsigned long long 类型的数据。 %zu 用于输出 size_t 类型的数据（在 printf 家族函数中，%zu 是专门用于 size_t 的格式化字符串）。 %zd 用于输出 ssize_t 类型的数据。 %p 用于输出指针类型的数据。 内核还提供了一些专门的输出函数，print_hex_dump 用于输出内存缓冲区中的数据，dump_stack 用于输出当前栈的信息。   动态输出技术 动态输出是内核子系统开发者非常喜欢的一项技术，因为它允许系统维护者动态地选择打开哪些内核子系统的输出。与全局的 printk 不同，动态输出可以有选择性地打开或关闭某些模块或函数的输出。 要使用动态输出，必须在配置内核时启用 CONFIG_DYNAMIC_DEBUG 宏。在内核代码中，大量使用了 pr_debug 或 dev_dbg 函数来输出信息，这些函数就利用了动态输出技术。 动态输出信息在 /sys/kernel/debug/dynamic_debug/control 文件中进行管理。这个文件记录了系统中所有使用动态输出技术的文件名路径、输出所在的行号、模块名字和要输出的语句。 通过向 /sys/kernel/debug/dynamic_debug/control 文件写入特定的命令，可以打开或关闭特定的动态输出语句。   printk函数介绍 printk函数是Linux内核提供的用于输出信息到内核日志的标准接口。它类似于C库中的printf函数，但有一些关键的区别和特性：   输出目标： printf函数将信息输出到标准输出设备（如显示屏或终端）。 printk函数则将信息输出到内核日志缓冲区，可以通过dmesg命令或查看/sys/kernel/printk文件来查看这些日志信息。 使用环境： printf函数主要用于用户空间程序。 printk函数则专门用于内核空间，因为内核无法像用户空间程序那样直接使用标准输出。 日志级别： printk支持不同的日志级别，KERN_EMERG（紧急）、KERN_ALERT（警告）、KERN_CRIT（严重错误）、KERN_ERR（错误）、KERN_WARNING（警告）、KERN_NOTICE（通知）、KERN_INFO（信息）和KERN_DEBUG（调试）等。这些级别有助于过滤和区分不同重要性的日志消息。 不可中断性： printf函数是可被中断的，输出内容可能会被其他程序打断。 printk函数则不会被中断，保证了输出的完整性。 使用printk进行内核调试 使用printk进行内核调试时，需要注意以下几点：   选择合适的日志级别： 根据调试信息的紧急程度和重要性选择合适的日志级别。 在生产环境中，应避免输出过多的调试信息（KERN_DEBUG级别），以免影响系统性能和日志的可读性。 避免频繁调用： 在性能敏感的地方频繁使用printk可能会导致性能下降。 可以通过条件输出和限制频率来优化printk的使用。 使用格式化字符串： printk的格式化字符串与printf类似，但应确保格式正确以避免输出错误的信息。 查看日志信息： 使用dmesg命令或查看/sys/kernel/printk文件来查看printk输出的日志信息。 在调试过程中，可以定期查看这些日志信息以了解系统的运行状态和调试进度。 结合其他调试工具： printk虽然强大，但并非万能的调试工具。在复杂的调试场景中，可以结合使用其他调试工具（gdb、kgdb、strace等）来共同定位问题。    

回复了主题帖： 《奔跑吧Linux内核2：调试与案例分析》并发与同步，自旋锁、互斥锁

okhxyyo 发表于 2025-2-10 15:59 谢谢楼主分享呀~高频面试题这里有答案吗？？？有谁来个解答

发表了主题帖： 《奔跑吧Linux内核2：调试与案例分析》信号量、中断和工作队列

《奔跑吧Linux内核2：调试与案例分析》一书中涵盖了信号量、中断和工作队列等Linux内核的重要概念。   信号量 信号量 信号量是一种用于进程或线程间同步的机制，它允许多个进程或线程访问同一资源，但会限制同时访问的进程或线程数量。在Linux内核中，信号量被广泛应用于各种同步场景。 信号量简介：信号量是一种计数器，用于记录可用资源的数量。当进程或线程需要访问资源时，会尝试获取信号量。如果信号量的值大于0，则获取成功，信号量值减1；如果信号量的值为0，则获取失败，进程或线程被阻塞等待。 信号量的操作：Linux内核提供了对信号量的操作函数，如down()和up()。down()函数用于尝试获取信号量，如果信号量不可用，则进程或线程会被阻塞；up()函数用于释放信号量，使信号量的值加1，并可能唤醒被阻塞的进程或线程。       信号量机制 信号量，作为操作系统中常用的同步原语，通过维护一个计数器来管理资源的访问。这个计数器表示了当前可用的资源数量。 信号量的两个关键操作是P（down）和V（up）： P操作（down）：尝试减少信号量的值。如果信号量的值大于0，表示有资源可用，P操作成功，信号量值减1，进程继续执行。如果信号量的值为0，表示没有资源可用，进程将被阻塞，进入睡眠状态，直到有资源被释放（即信号量值增加）。 V操作（up）：增加信号量的值。这通常表示一个资源被释放或创建。如果信号量的值增加后大于0，且有进程因为信号量值为0而被阻塞，那么这些进程中的一个将被唤醒，以继续执行。 在生产者和消费者问题中，信号量被用来同步生产者和消费者线程对缓冲区的访问。通常，会有两个信号量：一个用于表示空闲缓冲区的数量（empty），另一个用于表示已填充缓冲区的数量（full）。 生产者在生产商品时，会先尝试对empty信号量执行P操作。如果成功，表示有空闲缓冲区可用，生产者可以填充缓冲区，并将full信号量的值增加1。 消费者在消费商品时，会先尝试对full信号量执行P操作。如果成功，表示有已填充的缓冲区可用，消费者可以从缓冲区中获取商品，并将empty信号量的值增加1。     在尝试对信号量的count进行操作之前，代码首先使用mw_spin_lock_irqsave()函数来获取自旋锁，以保护对count的访问。这是因为count是一个共享资源，可能同时被多个进程或线程访问。 自旋锁通过忙等待的方式确保在持有锁的期间没有其他进程或线程能够修改count的值。 信号量的获取：当成功进入自旋锁的临界区后，代码检查sem->count的值。 如果sem->count大于0，表示有可用的信号量，进程可以成功获取信号量，并将sem->count的值减1。 如果sem->count小于或等于0，表示没有可用的信号量，进程无法立即获取信号量。 睡眠操作：当进程无法立即获取信号量时，它会调用down_interruptible()函数来执行睡眠操作。 down_interruptible()函数内部会调用_down_common()函数，该函数负责将进程添加到信号量的等待队列中，并设置进程的状态为TASK_INTERRUPTIBLE。 TASK_INTERRUPTIBLE状态表示进程可以被信号唤醒。如果进程在等待信号量时被信号打断，它将从睡眠状态中醒来，并从down_interruptible()函数中返回-EINTR错误码。 等待队列：在_down_common()函数中，使用struct semaphore_waiter数据结构来描述获取信号量失败的进程。 每个尝试获取信号量但失败的进程都会被添加到信号量的等待队列（sem->wait_list）中。 等待队列中的每个进程都有一个对应的semaphore_waiter结构体，该结构体包含了指向进程任务结构体的指针（waiter.task）和表示进程是否已被唤醒的标志（waiter.up）。 超时和中断处理：在等待信号量的过程中，进程可以设置一个超时时间（timeout）。如果超时时间到达，进程将从等待队列中删除，并从_down_common()函数中返回-ETIMEDOUT错误码。 如果进程在等待过程中被信号打断，它将从等待队列中删除，并从_down_common()函数中返回-EINTR错误码。     down 函数及其相关 down 函数（或其变体如 down_interruptible）的主要目的是尝试减少信号量的值。如果信号量的值已经是0，则当前进程将被阻塞，直到信号量的值被其他进程或线程增加。 自旋锁和等待队列：在进入临界区之前，down_interruptible 函数会获取信号量的自旋锁（sem->lock）。 如果信号量的值（sem->count）大于0，则直接减少它并释放锁。 如果信号量的值为0，则将当前进程（通过其 task_struct）加入等待队列（sem->wait_list）。 睡眠和唤醒：进程将其状态设置为 TASK_INTERRUPTIBLE 并调用 schedule_timeout 函数，传入 MAX_SCHEDULE_TIMEOUT 作为参数，这实际上会使进程进入睡眠状态，直到被唤醒或超时。 在调用 schedule_timeout 之前，会释放自旋锁，以避免在持有锁的情况下睡眠，这是不允许的。 当进程被唤醒时（可能是由 up 函数唤醒，或由信号中断），它会重新获取自旋锁并检查 waiter->up 标志。 如果 waiter->up 为 true，说明是由于信号量的 up 操作被唤醒，进程可以继续执行。 如果不是（比如由于信号或其他原因唤醒），则进程会跳转到错误处理代码。 up 函数 up 函数用于增加信号量的值，并可能唤醒在等待队列中睡眠的进程。 检查等待队列：如果等待队列为空（list_empty(&sem->wait_list)），则直接增加信号量的值（sem->count++）。 如果等待队列不为空，则调用 _up（或类似的内部函数，如你提到的 sched_up）来处理唤醒逻辑。 唤醒进程：从等待队列中取出第一个等待者（waiter）。 将 waiter->up 设置为 true。 调用 wake_up_process 函数唤醒该进程。   中断： 中断 中断是一种硬件机制，用于在处理器与设备之间传递异步事件的信号。当设备完成某个操作、出现错误或需要处理某个事件时，会发送一个中断信号给处理器。 中断的类型：在Linux内核中，中断可以分为硬件中断和软件中断。硬件中断是由外部设备触发的，键盘、鼠标等；软件中断则是由内核或用户进程触发的，如系统调用、异常处理等。 中断的处理：中断的处理过程包括中断的接收、识别和响应。当处理器接收到中断信号时，会立即中断当前正在执行的程序，转而执行与中断相关的处理程序。中断处理程序负责处理具体的中断事件，包括保存中断上下文、执行中断处理逻辑和恢复中断上下文等。 中断的优先级和嵌套：Linux内核支持中断的优先级和嵌套处理。高优先级的中断可以打断低优先级的中断处理程序，而低优先级的中断则必须等待高优先级的中断处理完成后才能被处理。Linux内核还提供了中断屏蔽机制，允许进程或线程在需要时屏蔽某些中断。   在LINUX系统中，中断可以根据其产生的方式和来源分为两大类：同步中断和异步中断。 同步中断：由CPU控制单元主动产生的，通常是在指令执行过程中发生的。由于这种中断是在指令执行完毕后才会被触发，因此称为“同步”。同步中断的一个典型例子是系统调用。根据Intel官方资料，同步中断通常被称为异常（Exception），并可以进一步细分为故障（Fault）、陷阱（Trap）和终止（Abort）三类。 异步中断：由外部硬件设备根据CPU的时钟信号随机产生的。这意味着异步中断可以在指令之间发生，例如键盘输入或网络数据到达。异步中断通常被称为中断（Interrupt），并可以进一步分为可屏蔽中断（Maskable Interrupt）和非屏蔽中断（Non-maskable Interrupt, NMI）两类。   中断控制器是计算机硬件中的一个组件，它的主要功能是接收来自硬件设备的中断信号，并根据这些信号的类型和优先级，将它们转发给CPU进行处理。在Linux内核中，中断控制器的管理涉及多个层次，包括硬件层、处理器架构管理层、中断控制器管理层以及Linux内核通用中断处理器层。   不同的处理器架构对中断控制器有着不同的设计理念。例如，ARM公司提供了一个通用中断控制器（Generic Interrupt Controller，GIC），而x86架构则采用高级可编程中断控制器（Advanced Programmable Interrupt Controller，APIC）。这些中断控制器都是为了更有效地管理和分发中断信号而设计的。   以ARM Vexpress V2P-CA9平台为例，它支持GIC Version 2（GIC-V2）。 中断状态： 不活跃（inactive）状态：中断处于无效状态，即没有中断信号被触发。 等待（pending）状态：中断处于有效状态，但等待CPU响应。这表示中断信号已经被触发，但CPU尚未开始处理。 活跃（active）状态：CPU已经响应中断，并开始执行中断服务程序。 活跃并等待（active and pending）状态：CPU正在响应一个中断，但该中断源又发送了另一个中断信号。这通常发生在中断服务程序尚未执行完毕时，同一个中断源再次触发中断。 中断触发方式： 边沿触发（edge-triggered）：当中断源产生一个上升沿或下降沿时，触发一个中断。这种方式适用于那些信号变化较快且需要精确捕捉的设备。 电平触发（level-sensitive）：当中断信号线产生一个高电平或低电平时，触发一个中断。这种方式适用于那些信号状态持续较长时间且需要持续响应的设备。 硬件中断号： GIC为每一个硬件中断源分配一个中断号，这称为硬件中断号。这些中断号用于在中断控制器中唯一标识每个中断源。 GIC会根据支持的中断类型分配中断号范围。SGI（Software Generated Interrupt，软件生成中断）、PPI（Private Peripheral Interrupt，私有外设中断）和SPI（Shared Peripheral Interrupt，共享外设中断）等不同类型的中断会有不同的中断号范围。     中断检测与标记： 当GIC检测到一个中断发生时，它首先会将该中断标记为pending状态。这表示中断已经被GIC感知，但尚未被CPU处理。 目标CPU确定： 对于处于pending状态的中断，GIC的仲裁单元会确定目标CPU。这一过程涉及中断的路由和分发，确保中断被发送到正确的CPU上进行处理。 优先级选择与发送： 仲裁单元会从众多处于pending状态的中断中选择一个优先级最高的中断。这是通过比较各个中断的优先级来实现的。 一旦选择了最高优先级的中断，仲裁单元会将其发送到目标CPU的CPU接口模块上。 CPU接口模块决策： CPU接口模块会检查该中断的优先级是否满足要求。如果满足，GIC会发送一个中断请求信号给该CPU。 CPU响应中断： 当一个CPU进入中断异常后，它会读取GICC_IAR寄存器来响应该中断。这通常由Linux内核的中断处理程序来完成。 读取GICC_IAR寄存器后，CPU会获得硬件中断号（hardware interrupt ID）。对于SGI（软件触发中断）来说，返回的是源CPU的ID（source processor ID）。 中断状态更新与处理： 当GIC感知到软件读取了GICC_IAR寄存器后，它会根据中断的当前状态进行更新。如果该中断仍处于pending状态，则状态将变成active。 如果该中断又重新产生，则pending状态将变成active and pending状态。 如果该中断已经处于active状态，则将变成active and pending状态。 CPU随后会执行相应的中断服务程序来处理该中断。 中断处理完成： 当处理器完成中断服务后，必须发送一个完成信号（End Of Interrupt, EOI）给GIC。 GIC收到EOI信号后，会将该中断的状态从active and pending更改为inactive，从而允许其他pending的中断被处理。           QEMU 虚拟机的中断分配：     工作队列： 工作队列 工作队列是一种将延迟执行的任务交给内核线程处理的机制。它允许内核或驱动在需要时提交任务给工作队列，并由内核线程在合适的时机执行这些任务。 工作队列的组成：工作队列由工作项（work item）和工作者线程（worker thread）组成。工作项是需要被延迟执行的任务，而工作者线程则是负责执行这些任务的线程。 工作队列的创建和初始化：在Linux内核中，可以使用create_workqueue()函数创建一个新的工作队列，或使用system_wq等默认工作队列。创建工作队列后，需要使用INIT_WORK()宏初始化一个工作项，并指定该工作项的处理函数。 工作项的调度和执行：初始化完工作项后，可以使用schedule_work()或queue_work()函数将工作项提交给工作队列。内核线程会在合适的时机（如中断处理程序返回、系统空闲等）执行这些工作项。执行过程中，工作项的处理函数会被调用，以完成具体的任务。 工作队列的取消和销毁：在需要时，可以使用cancel_work_sync()等函数取消正在等待或正在执行的工作项。此外，当不再需要使用工作队列时，可以使用destroy_workqueue()函数销毁该工作队列。   工作队列的相关数据结构：   示例与解释：   相关的解释：   数据结构的描述：   工作队列初始化：     创建Slab缓存对象： workqueue_init_early() 函数首先会创建一个用于存储pool_workqueue数据结构的Slab缓存对象。Slab分配器是Linux内核中一种高效的内存分配机制，用于分配和释放固定大小的对象。 为每个CPU创建工作线程池： 接下来，该函数会为系统中所有可用的CPU（通过cpu_possible_mask确定）分别创建工作线程池。对于每个CPU，都会创建两个工作线程池：一个用于普通优先级的工作，另一个用于高优先级的工作。这是通过调用init_worker_pool()函数并传入相应的参数来实现的。 for_each_cpu_worker_pool()宏用于遍历每个CPU的两个工作线程池，并对它们进行初始化。这个宏实际上是一个循环，它会遍历每个CPU的per_cpu(cpu_worker_pools, cpu)数组中的元素，直到达到NR_STD_WORKER_POOLS（标准工作线程池的数量）为止。   创建工作队列属性： 函数会创建两种类型的工作队列属性：UNBOUND类型和ordered类型。UNBOUND类型的工作队列允许工作项在任何CPU上执行，而ordered类型的工作队列则保证同一个时刻只能有一个工作项在运行。 创建系统默认的工作队列： 最后，该函数会使用alloc_workqueue()接口函数创建系统默认的几个工作队列。这些工作队列包括： 普通优先级、BOUND类型的工作队列system_wq，名称为“events”。 高优先级、BOUND类型的工作队列system_highpri_wq，名称为“events_highpri”。 UNBOUND类型的工作队列system_unbound_wq，名称为“system_unbound_wq”。 Freezable类型的工作队列system_freezable_wq，名称为“events_freezable”。这种类型的工作队列可以在系统进入挂起状态时被冻结。 省电类型的工作队列system_power_efficient_wq，名称为“events_power_efficient”。这种类型的工作队列旨在通过优化CPU使用来降低功耗。 创建工作线程： 在系统初始化期间，当init进程被初始化时，会调用workqueue_init()函数来创建实际的工作线程。这些工作线程将负责执行工作队列中的工作项。

发表了主题帖： 《奔跑吧Linux内核2：调试与案例分析》并发与同步，自旋锁、互斥锁

本帖最后由 meiyao 于 2025-2-10 14:53 编辑 计划用10天左右的时间阅读第一二章节：并发与同步，自旋锁、互斥锁、信号量、中断和工作队列等。   在 Linux 系统中，并发与同步是非常重要的概念，而自旋锁、互斥锁、信号量、中断和工作队列是实现并发控制与同步的关键机制,下面我坐并发与同步开启我的学习。   一、并发与同步 并发与同步概述 在多任务的 Linux 环境下，多个执行单元（如进程、线程、中断处理程序等）可能会同时访问共享资源。如果没有合适的同步机制，就可能导致数据不一致、程序崩溃等问题。并发控制的目的就是确保多个执行单元对共享资源的访问是有序的，避免竞态条件的发生。 下图是开章的试题，我感觉这个题有些很有代表性： 1、在 ARM64 处理器中，如何实现独占访问内存? 在 ARM64 处理器中，可以通过使用原子指令（如 LDXR、STXR 等）或互斥锁（mutex）来实现独占访问内存。原子指令可以确保在执行过程中不会被其他线程或进程打断，从而实现独占访问。互斥锁则是一种更高级的同步机制，用于保护共享资源或临界区免受并发访问的影响。 3、在 ARM64中，CAS 指令包含了加载-获取和存储-释放指令，它们的作用是什么? CAS（Compare-And-Swap）指令在 ARM64 中通常包含加载-获取（load-acquire）和存储-释放（store-release）指令。加载-获取指令用于从内存中原子地加载一个值，并确保在该加载操作之前的所有写操作对于其他观察者来说都是可见的。存储-释放指令则用于原子地将一个值存储到内存中，并确保在该存储操作之后的所有写操作对于其他观察者来说都是可见的。 10、Linux内核中经典自旋锁的实现有什么缺点? Linux内核中经典自旋锁的实现可能存在以下缺点： 忙等待：自旋锁在无法获得锁时会持续检查锁的状态，这会导致CPU资源的浪费。 可扩展性差：在多核处理器上，自旋锁的性能可能会随着核数的增加而下降。 优先级反转：自旋锁可能导致优先级反转问题，即低优先级的线程持有锁而高优先级的线程被阻塞。             并发访问的来源 中断和异常：中断处理程序可能会打断正在执行的进程，导致中断处理程序和进程之间对共享资源的并发访问。 需要确保中断处理程序访问共享资源时的原子性。 软中断和tasklet：软中断和tasklet可以随时被调度和执行，从而打断当前进程上下文。 同样需要保护对共享资源的访问，避免并发问题。 内核抢占：在支持内核抢占的系统中，调度器可以抢占正在执行的进程，重新调度其他进程。 这可能导致不同进程之间对共享资源的并发访问。 多处理器并发执行：在多处理器系统中，多个CPU可以同时执行内核线程或进程。 需要特别注意跨CPU的并发访问问题。   保护共享资源的策略 禁用中断：在访问临界区之前禁用中断，确保在访问期间不会有中断处理程序打断。 但这种方法会降低系统响应性，应谨慎使用。 自旋锁（spinlock）：自旋锁适用于短时间保护的临界区。 当一个CPU持有锁时，其他尝试获取锁的CPU会忙等待（自旋），直到锁被释放。 互斥锁（mutex）：互斥锁适用于需要较长时间保护的临界区。 当锁被持有时，其他尝试获取锁的线程会被阻塞，直到锁被释放并被唤醒。 读写锁（rwlock）：读写锁允许多个读者同时访问，但写者独占访问。 适用于读多写少的场景。 顺序锁（seqlock）：顺序锁适用于读多写少的场景，且对性能要求较高。 通过版本号机制来检测数据的一致性，读者不需要持有锁即可读取数据。 原子操作：对于简单的计数器或标志位，可以使用原子操作来保证操作的原子性。 内存屏障（memory barrier）：内存屏障用于确保指令的执行顺序，防止编译器或CPU重排序导致的并发问题。       二、自旋锁（Spin Lock） 原理：自旋锁是一种忙等待锁。当一个执行单元尝试获取自旋锁时，如果锁已经被其他执行单元持有，该执行单元会一直循环检查锁的状态，直到锁被释放。这种方式会让 CPU 一直处于忙等待状态，不会进行上下文切换。 使用场景：适用于锁被持有时间非常短的场景，因为上下文切换的开销相对较大，如果锁的持有时间短，自旋等待的时间成本会低于上下文切换的成本。在中断处理程序中对共享数据的访问，由于中断处理程序执行时间通常较短，使用自旋锁可以避免不必要的上下文切换。       自旋锁适用于短时间保护的临界区。 当一个CPU持有锁时，其他尝试获取锁的CPU会忙等待（自旋），直到锁被释放。   理解的代码： #include <linux/spinlock.h> spinlock_t my_spinlock; // 初始化自旋锁 spin_lock_init(&my_spinlock); // 获取自旋锁 spin_lock(&my_spinlock); // 临界区代码 // ... // 释放自旋锁 spin_unlock(&my_spinlock); 例子：       变体的介绍：       自旋锁与中断 在Linux内核中，spin_lock_irqsave()和spin_lock_irq()是自旋锁的两种变体，它们的主要区别在于是否保存和恢复中断状态。 spin_lock_irqsave()：在获取自旋锁之前，它会保存当前CPU的中断状态并关闭中断。这意味着在持有锁期间，当前CPU不会响应任何中断。当释放锁时，它会恢复之前保存的中断状态。 spin_lock_irq()：它直接关闭当前CPU的中断并获取自旋锁，但不保存中断状态。这意味着在释放锁时，中断将保持关闭状态，直到显式地重新启用它们。 关闭中断的目的是防止在持有自旋锁期间发生中断上下文中的竞争条件，因为中断处理程序可能会尝试获取相同的锁。   关于CPU间的死锁问题 您提到的场景是：CPU0持有自旋锁，CPU1响应外部中断并尝试获取相同的锁。由于CPU0很快会离开临界区并释放锁，CPU1上的中断处理程序可以很快获得该锁。这种情况下不会发生死锁，因为自旋锁是非阻塞的，即如果锁不可用，请求锁的线程会忙等待（自旋）直到锁变为可用。   进程切换与自旋锁 在持有自旋锁期间，通常不应该发生进程切换，因为自旋锁通常用于保护非常短的临界区代码。在进入自旋锁之前，通常会调用preempt_disable()来禁用抢占，以确保在持有锁期间不会被抢占。 如果驱动编写者违反了这一原则，在持有自旋锁的情况下调用可能导致睡眠的函数（如没有使用GFP_ATOMIC标志的kmalloc()），那么确实可能会导致问题。这种调用可能会导致当前进程被挂起，从而允许其他进程或中断处理程序运行并尝试获取相同的锁，这可能导致死锁或优先级反转等问题。   自旋锁bh（bottom half） spin_lock_bh()是另一种自旋锁的变体，它用于处理与软中断（bottom halves）相关的并发问题。在获取spin_lock_bh()之前，它会禁用当前CPU的软中断（包括任务队列和定时器软中断），然后获取自旋锁。当释放锁时，它会重新启用软中断。     排队自旋锁：     Qspinlock数据结构 Qspinlock数据结构依然采用了自旋锁的基本结构，但进行了优化以适应排队机制。  locked：表示锁是否已经被某个CPU所持有。 pending：表示是否有CPU在等待获取锁。 tail：用于指向自旋锁队列的最后一个节点，从而方便新加入的CPU找到队列的尾部并加入等待。 这些字段通过位操作进行高效的管理和访问。   工作原理 排队自旋锁的工作原理如下： 当一个CPU尝试获取锁时，它首先检查locked字段。如果locked为0，表示锁空闲，该CPU可以设置locked为1并成功获取锁。 如果locked为 表示锁已经被其他CPU持有。此时，该CPU会检查pending字段。如果pending为0，表示当前没有其他CPU在等待锁，该CPU可以设置pending为1并成为等待队列中的第一个节点。 如果pending已经为1，表示已经有其他CPU在等待锁。该CPU会将自己的信息加入到等待队列的尾部，并在自己的节点上自旋等待。 当持有锁的CPU释放锁时，它会检查等待队列，如果队列为空，则直接释放锁。如果队列不为空，则它会将锁传递给队列中的下一个节点，并通知该节点获取锁。   Qspinlock中VAL字段的含义：     快速通道 当自旋锁没有被持有时，即 lock->val 等于 0，queued_spin_lock() 函数会尝试通过快速通道获取锁。这是通过调用 atomic_try_cmpxchg_acquire() 函数来实现的。 atomic_try_cmpxchg_acquire() 函数会尝试比较 lock->val 和某个期望值（在这个场景下是 0）。 如果比较结果相等，说明当前没有其他 CPU 持有锁，那么该函数会将 lock->val 设置为 _QLOCKED_VAL（一个特定的值，表示锁已被当前 CPU 快速持有）。 如果 atomic_try_cmpxchg_acquire() 返回 true，则表示成功获取了锁，函数结束。     中速申请通道：         慢速通道 如果自旋锁已经被持有，即 lock->val 不等于 0，queued_spin_lock() 函数会转到慢速通道中。 在慢速通道中，会调用 queued_spin_lock_slowpath() 函数来处理锁的获取。 这个函数会负责将当前 CPU 加入到等待队列中，并在适当的时机尝试重新获取锁。 慢速通道可能涉及更多的上下文切换和忙等待，因此性能相对较低，但在锁争用激烈的情况下是必要的。       总结： 原始自旋锁（Raw Spinlock） 定义：原始自旋锁是最基本的自旋锁类型，本质上就是一个无符号整数，用于表示锁的状态。 特点：它提供了最底层的锁机制，没有额外的调试或日志记录功能。适用于对性能要求极高，且不需要调试信息的场景。 读写自旋锁（Read-Write Spinlock） 定义：读写自旋锁允许多个读者（线程）同时访问共享资源，但写者（线程）在写入时必须独占资源。 特点：提高了读操作的并发性，因为读操作不会阻塞其他读操作。但在写操作时，会阻塞所有其他读操作和写操作。适用于读多写少的场景。 顺序锁（Seqlock） 定义：顺序锁是一种用于保护顺序数据结构的自旋锁。它允许读者在不持有锁的情况下读取数据，但写者在更新数据时必须持有锁。 特点：通过维护一个序列号来确保读者读取到的是一致的数据版本。读者在读取数据时检查序列号，如果序列号在读取过程中没有变化，则认为数据是一致的。适用于读操作远多于写操作的场景，且对读操作的实时性要求较高。 其他变体 除了上述三种基本的自旋锁类型外，Linux内核还实现了其他一些自旋锁的变体，以适应特定的使用场景： 排队自旋锁：通过保存执行线程申请锁的顺序信息来解决“不公平”问题。它仍然使用原始自旋锁的数据结构，但赋予了锁状态字段新的含义，以保存锁持有者和未来锁申请者的顺序信息。 MCS自旋锁：基于链表结构的自旋锁，每个锁的申请者（处理器）只在一个本地变量上自旋，避免了所有申请者都在同一个共享变量上自旋导致的性能问题。 Ticket自旋锁：类似于排队自旋锁，但实现方式略有不同。它使用两个原子整数来表示锁的申请者和持有者的票据序号，通过比较票据序号来决定是否获得锁。  

回复了主题帖： 【新年花灯】经典精灵球

玩的真的6啊

回复了主题帖： 测评入围名单： 树莓派Pico 2 RP2350开发板

个人没有什么问题，会在时间内完成测评

回复了主题帖： 【测评入围名单（最后1批）】年终回炉：FPGA、AI、高性能MCU、书籍等65个测品邀你来~

个人信息无误，确认可以完成测评计划

加入了学习《直播回放: ROHM 重点解析双极型晶体管的实用选型方法和使用方法》，观看 ROHM - 双极晶体管的选型和使用方法

回复了主题帖： 新年新挑战，任务打卡赢好礼！

1、更新完善个人信息：完善您的个人资料，让我们更好地了解您。 2、回复3个帖子：在论坛中积极参与讨论，分享您的见解与心得。 3、认真学完1个大学堂视频：提升自我，获取知识，享受学习的乐趣。   4、报名参加活动中心的1个活动：融入社区，与更多志同道合的人一起共度美好时光。 5、下载一份资源站资料：获取您需要的资源，助力您的学习与工作。  

回复了主题帖： 加速电机控制器开发：EasyGo硬件在环测试平台一站式解决方案

电机控制一直都是非常不错的应用，楼主说的很全面.

回复了主题帖： E2PROM的数据怎么读取出来？

E2PROM的数据可以通过I2C总线接口读取出来。

回复了主题帖： 【Follow me第二季第4期】-任务提交与汇总

PDM麦克风，是采用脉冲密度调制，通过调整连续脉冲序列中1和0的密度来代表模拟信号的幅度。

回复了主题帖： 【回顾2024，展望2025】新年抢楼活动来啦！

立一个新年Flag，EEWORLD加油 最想关注是AI,FPGA,LINUX的技术。 最想要的是FPGA开发板，linux开发板，多一些这方面的资料学习.

回复了主题帖： 【回顾2024，展望2025】新年抢楼活动来啦！

立一个新年Flag，EEWORLD加油 最想关注是AI,FPGA,LINUX的技术。 最想要的是FPGA开发板，linux开发板，多一些这方面的资料学习.

回复了主题帖： 【回顾2024，展望2025】新年抢楼活动来啦！

立一个新年Flag，EEWORLD加油 最想关注是AI,FPGA,LINUX的技术。 最想要的是FPGA开发板，linux开发板，多一些这方面的资料学习.

回复了主题帖： 【回顾2024，展望2025】新年抢楼活动来啦！

立一个新年Flag，EEWORLD加油