Infinity项目中的HNSW索引构建数据竞争问题分析

问题背景

在Infinity数据库系统的开发过程中，我们发现了一个与HNSW(可导航小世界图)索引构建相关的数据竞争问题。这个问题主要出现在多线程环境下进行内存索引构建时，涉及到线程池管理和条件变量的使用。

问题现象

通过ThreadSanitizer工具检测，我们观察到了多个线程对同一内存地址的竞争访问。具体表现为：

1. 一个线程正在执行operator delete操作，释放内存
2. 另一个线程同时在进行条件变量的等待操作(pthread_cond_wait)
3. 竞争发生在std::promise对象的析构过程中

这种数据竞争可能导致程序出现未定义行为，包括内存访问违规、程序崩溃等严重后果。

技术分析

竞争发生的根本原因

问题的核心在于线程池中的工作线程与索引构建线程之间的同步问题。具体来说：

1. 线程生命周期管理不当：当线程池调整大小时，旧线程的清理与新线程的创建没有完全同步
2. 共享状态访问冲突：多个线程同时访问了std::promise对象的状态标志
3. 条件变量使用问题：在条件变量等待期间，相关的互斥锁保护不够完善

涉及的关键组件

1. CTPL线程池：用于管理索引构建的工作线程
2. HNSW索引构建器：负责在内存中构建HNSW索引结构
3. 条件变量和互斥锁：用于线程间同步

解决方案

针对这个问题，我们采取了以下改进措施：

1. 加强线程同步：在调整线程池大小时，确保所有旧线程完全退出后再创建新线程
2. 改进共享状态管理：使用原子操作保护std::promise的状态标志访问
3. 优化条件变量使用：确保在条件变量等待期间持有正确的互斥锁
4. 资源释放顺序调整：确保所有工作线程完成后再释放相关资源

实现细节

在具体实现上，我们对以下关键部分进行了修改：

1. 线程池调整逻辑：

   • 先停止所有工作线程
   • 等待所有线程确认退出
   • 然后才创建新线程

2. 索引构建任务管理：

   • 使用更安全的std::shared_future替代部分std::promise使用场景
   • 为每个任务分配独立的资源，减少共享状态

3. 错误处理增强：

   • 添加了更完善的错误检测机制
   • 确保资源异常时能够安全释放

性能影响

这些改进虽然增加了一些同步开销，但对整体性能影响有限：

1. 线程池调整不是高频操作
2. 索引构建本身是CPU密集型任务，同步开销占比小
3. 改进后系统稳定性显著提升

经验总结

通过解决这个问题，我们获得了以下经验：

1. 多线程资源管理：必须谨慎处理线程生命周期和资源释放顺序
2. 工具使用：ThreadSanitizer等工具对检测并发问题非常有效
3. 设计原则：减少共享状态是避免数据竞争的有效方法
4. 测试重要性：需要加强多线程场景下的压力测试

这个问题提醒我们在高性能数据库系统开发中，必须对并发控制给予足够重视，特别是在涉及复杂数据结构和多阶段任务时。