云优化引擎创业：Rust vs C++ 的技术选型困境

背景情况

• 创业者计划在希腊建立云优化平台创业公司
• 同时掌握 Rust 和 C++ 两种语言
• 已用 Rust 开始开发，但考虑转向 C++
• 核心顾虑：不是技术问题，而是招聘和商业问题

关键挑战

团队需求

• 初期可能独自工作1个月，之后必须招聘2-3名程序员
• 第一年引擎规模不会小，需要尽早招人
• 融资前预算非常有限，只能提供较低薪资

招聘困境（希腊本地市场）

• Rust 程序员极难找到，C++ 程序员相对容易
• 预计需要4-6个月才能找到第一位中级 Rust 程序员
• 第一年内可能无法组建完整的 Rust 团队

投资者考量

• 6-12个月后寻求投资时，投资者不关心用 Rust 还是 C++
• 投资者关心是否有功能性团队
• 远程招聘国外程序员可能不受投资者欢迎

两难选择

选项A - 坚持 Rust

• ✅ 技术优势明显，适合大型云优化引擎
• ✅ 更好的内存安全和可靠性
• ❌ 可能长达一年找不到合适程序员
• ❌ 团队组建困难

选项B - 转向 C++

• ✅ 招聘容易快速
• ✅ 更容易组建团队
• ❌ 内存管理问题、难以发现的 bug、安全漏洞
• ❌ 即使借助 AI 工具辅助，隐藏问题仍难避免

已排除方案

• ❌ 远程招聘：投资者可能不喜欢，存在沟通管理问题
• ❌ 引擎用 Rust + 其他部分用 C++：引擎太大，拆分无意义

https://old.reddit.com/r/rust/comments/1s2x4z3/rust_or_c_for_a_cloud_optimization_engine_not_a/

无锁持有的死锁：在没有持有锁的情况下让 Tokio Mutex 死锁

问题概述

在一个使用 Tokio 的 Rust 程序中，团队遇到了一个反直觉的死锁现象：

• 使用单个 tokio::sync::Mutex 保护共享状态
• 4个异步任务启动，3个完成，第1个永久挂起
• 关键矛盾：日志显示互斥锁已经释放，但任务仍然被阻塞
• 这不是经典的在 .await 中持有 std::mutex 的错误

复现代码要点

• 使用 tokio::sync::Mutex 被4个 worker 并发访问
• 实现了 PausableFuture 包装器，收到信号时停止轮询内部 future
• 使用单线程的 current_thread 运行时（多线程运行时也有类似行为）

执行流程

1. 主线程获取锁
2. 启动4个 worker，每个都有独立的停止标志
3. 让出执行权，让所有 worker 开始等待锁
4. 关键操作：停止 worker 1 的轮询
5. 主线程释放锁

实际结果

main released the lock
worker 0: acquired lock
worker 0: released lock
worker 0: done
worker 1: DEADLOCKED
worker 2: DEADLOCKED
worker 3: DEADLOCKED

异常现象：主线程和 worker 0 都已释放锁，没有人持有锁，但其他线程仍然死锁！

实际生产环境背景

• 发生在基于 DataFusion 构建的查询引擎中
• 只在特定工作负载中出现
• 涉及暂停和恢复流的操作

调试方向：Coffman 条件

文章开始检查死锁的 Coffman 条件：

1. 互斥：使用 mutex，满足 ✅
2. 持有并等待：只有一个资源...（内容未完）

这是一个深入 Tokio 内部机制的技术案例，展示了异步编程中的微妙陷阱。

https://www.e6data.com/blog/deadlocking-tokio-mutex-without-holding-lock

--

From 日报小组 Mike

社区学习交流平台订阅：

• Rustcc论坛: 支持rss
• 微信公众号：Rust语言中文社区