编写安全代码：避免奇怪的逻辑引发的bug

最新推荐文章于 2022-06-08 21:48:01 发布

zheguangqi

最新推荐文章于 2022-06-08 21:48:01 发布

阅读量341

点赞数

作者：gfree.wind@gmail.com
博客：blog.focus-linux.net linuxfocus.blog.chinaunix.net

本文的copyleft归gfree.wind@gmail.com所有，使用GPL发布，可以自由拷贝，转载。但转载请保持文档的完整性，注明原作者及原链接，严禁用于任何商业用途。

======================================================================================================

本文来自今天修改的一个Bug。Bug的产生完全是由于一段不合理或者奇怪的逻辑引发的。代码大致如下：

void reset_res(res_config, new_res)
{
old_res = res_config->res;
res_config->res = new_res;
barrier();
free_res(old_res);
}
int modify_config()
{
new_res_config = duplicate(old_res_config);
new_res = new_res();
reset_res(new_res_config, new_res)
config->res_config = new_res_config;
barrier();
free_res_config(old_res_config);
}

其中barrier可以保证所有的工作线程完成了一个循环。在reset_res中的barrier后，就保证了没有任何线程引用old_res这一地址，这样后面就可以安全的调用free_res释放old_res指向的资源了。而modify_config中的barrier同样保证了barrier后，没有任何线程再引用old_res_config了。

看上去代码写得很严谨，甚至使用了barrier保证了资源的安全释放。这样保证了不使用任何锁的条件下，完成了配置的变化。看上去很美很不错，然而却由于modify_config的不合理甚至有些奇怪的逻辑，导致了bug的产生。

下面说一下bug是如何发生的：

1. modify_config用于不阻塞工作线程的条件下，修改配置；

2. 为了不阻塞工作线程，利用替换指针和barrier来完成配置的修改；

3. new_res_config = duplicate(old_res_config)复制旧的配置；

4. 配置不同，需要新的资源new_res，然后调用reset_res完成res的替换和释放；

5. config->res_config = new_res_config; barrier()完成配置的更新；

Bug就出现在第三步。调用duplicate后，new_res_config和res_config指向了同一份资源，然后在reset_res中，这份资源被释放，而new_res_config指向了新的资源。这时bug出现了。因为目前的应用的配置仍然是res_config，其仍然指向旧资源，然而旧资源已经被释放。

那么如何修改这个Bug呢？将第5步放到reset_res之前，代码示意如下：