C语言开发线程安全库：内部实现同步还是交由用户处理？

关于库线程安全方案选型的解答 #

两种方案不存在绝对的通用最佳实践，需要结合你的库定位、目标用户、性能要求综合判断：

方案1：库内部内置线程安全

这一方案的应用场景非常广泛，你提到的为可变对象内置互斥锁、访问器自动加锁的实现方式，在GTK、主流数据库客户端库等大量面向通用场景的开源项目中都有使用。

• 优势：对调用者非常友好，普通开发者不需要额外学习并发知识就能在多线程场景下安全使用库，能大幅降低调用方的bug率。
• 劣势：首先会带来固定的性能开销，哪怕在单线程场景下使用也会产生锁操作的成本；其次如果锁粒度设计不合理，反而容易引发死锁问题——比如用户同时操作两个库对象时，加锁顺序相反就会触发死锁，这类问题排查难度极高；另外如果调用方需要做原子性的批量操作，单个访问器独立加锁的设计根本无法满足需求，调用方还是需要在外层额外加锁，反而会造成双重锁的冗余开销。

方案2：调用方自行负责同步

这是高性能基础库的主流选择，比如C标准库的基础数据结构实现、C++ STL的所有容器默认都采用这一策略，要求调用方自行保障跨线程访问的安全性。

• 优势：库本身没有额外的性能开销，灵活性极强，调用方可以根据自己的业务场景选择最合适的同步策略：单线程场景完全不需要加锁，批量操作可以加一次全局锁完成所有操作，反而比库内部加锁的性能更高。
• 劣势：对调用者的开发能力要求较高，经验不足的开发者很容易写出存在数据竞争、死锁的代码，且问题排查时很难界定是库本身的问题还是调用方的同步逻辑问题。

选型建议&问题答复

1. 完全在库内部处理线程安全并非行业公认的通用最佳实践，只是不同场景下的合理选型之一，不存在绝对的对错。
2. 把同步工作交给调用方确实会降低库的开发难度，但是不一定会带来额外的使用开销：对于有并发开发经验的开发者来说，自主控制同步粒度往往能获得比库内置锁更好的性能；只有针对经验不足的普通开发者，这一方案才会带来额外的学习和开发成本。

如果想要兼顾两种方案的优势，你也可以选择折中实现：比如在对象初始化时提供参数让用户选择是否开启内置锁，或者提供编译选项分别生成带锁/不带锁的库版本，同时在文档中明确标注不同版本的使用规则即可。

内容的提问来源于stack exchange，提问作者Drobot Viktor