C | Tony Bai - Part 114

使用astyle美化代码

七月 29, 2010

昨天一位同事发了一篇小文档，文档中介绍了一种开源格式化代码的工具，名为Artistic Style(astyle)，功能看起来还是很不错的。之前我写代码时比较注意代码的风格，一直按照自己的思路来美化自己的代码，用的最多的辅助工具就是Vim自带的indent功能，对这之外的格式化工具少有涉猎。记得几年前部门曾推广一款名为checkstyle的Java代码格式规范检查工具，由于当时基本不接触Java，也没有用过。

今天被问及该工具是否可以在组内推广，遂又花心思想了一下。看了同事的介绍文档，感觉astyle还是很实用的，特别是对现存遗留的格式不规范的代码文件，可批量做转换(之前我都是修改哪个源文件时顺便对格式进行美化，浪费了我不少精力) 但是如何能被大家接受和使用起来，这还是一个问题。最开始想到的是让astyle与svn结合在一起，对开发人员保持透明。通过svn hooks来自动完成对代码的格式化。不过细致研究后发现，这样是有问题的。如果在svn server端增加svn pre-commit hook来调用astyle对提交的代码进行格式化，那么这势必可能导致开发人员提交后的server端代码与其Local copy不一致；如果开发人员不知情，后续就会导致进一步的代码不一致问题。另外在svn官方manual中似乎也不推荐在svn pre-commit hook中修改提交的文件内容，好像是会破坏svn commit事务（导致本地和服务器端的一些对文件的统计不一致）。又考虑在客户端svn hook，可查来查去才发现目前只有TortoiseSVN的实现支持客户端hook，遂放弃。

让大家直接执行astyle，显然是高估了大家的执行力了。遂想到还是将astyle与Vim集成在一起吧。

步骤如下：
1、编译artistic style源码，将astyle的可执行程序放到某个目录X下，并将目录X放到path中（ubuntu上可用sudo apt-get install astyle安装）
2、编辑.vimrc，添加一行map :%! astyle （Shift+F 注：在当前缓冲区用astyle美化缓冲区中的内容，并输出结果到当前缓冲区中）
3、定义模板option文件，位置:$HOME/.astylerc

以下是一个.astylerc的例子：
# my astyle options file

–indent=spaces=8
–brackets=attach
–indent-switches
–indent-cases
–indent-labels
–indent-preprocessor
–indent-col1-comments
–pad-oper
–pad-header
–unpad-paren
–add-brackets
–keep-one-line-statements
–align-pointer=name
–mode=c
–min-conditional-indent=0

按照以上方式集成astyle到vim中有一个缺点：就是每次美化都是针对当前缓冲区（一般就是一个文件）。无法做到对某几行或一块区域进行代码美化。

后在stackoverflow上发现有一人提出这样的方案：在.vimrc中增加一行：autocmd BufNewFile,BufRead *.c set formatprg=astyle\ -T4pb。最初以为这样设置是使用astyle替换vim内置的c indent格式化工具，遂照猫画虎配置后用"="命令进行测试，发现无法格式化；遂花时间研读Vim手册，终于发现是我的理解错了。formatprg这个option是与gq命令联系在一起的，而非关联"="命令。以前的确不怎么使用gq命令，而是一直用c indent("=")来做所谓的格式化操作。利用对formatprg这个option的设置可以做到利用外部工具对vim当前文本buffer做格式化的目的。因为之前已经配置了$HOME/.astylerc，所以在.vimrc中增加一行：autocmd BufNewFile,BufRead *.c set formatprg=astyle，去掉了-T4pb这几个参数。

生效.vimrc后使用gq命令对.c文件进行测试，果然有效。gq命令不仅支持对Whole Buffer进行filter，而且可以对单行、多行以及对块文本进行格式化过滤，比如：
NORMAL模式下: gggqG 即对Whole Buffer进行格式化过滤；
gqG 对从当前行到末尾行之间的文本进行格式化过滤；
gq+1 对下一行文本进行格式化过滤；
gqj 对当前行和下一行文本进行格式化过滤；

与Vim结合在一起最大的好处是：astyle被透明的引入到我们日常开发过程中了，你的工作量并未因astyle的引入而增加，反而astyle却提升了你的工作效率，不是吗？

慎用线程取消

本周二，我们产品在某省的一个节点应用运行时出现了“死锁”情况，由于监控得力，我们在“死锁”后一分钟内就发现了这个情况，并及时重启了这个节点应用。由于是集群式系统，一个节点的故障对整个系统业务的运行几乎没造成什么影响。不过，这确是一个潜在的隐患。

经过对系统当时运行日志的分析，我们将问题锁定在“线程取消”这个机制的使用上。在“生产者-消费者”实现思路这篇文章中，我曾经提到过我们目前采用的一种通知机制的实现。消费者进程的主线程创建一个子线程，后者一般挂起在条件变量上等待生产者侧的唤醒。一般情况下，这种机制运行都很良好，问题出就出在消费者进程要退出的时候。

这个机制的实现也是逐渐“改”过来的。最初发现消费者进程退出时子线程长时间无法被唤醒导致无法及时退出，主线程因为要Join子线程，所以也阻塞在Join上，两个线程都挂起了，进程也就无法退出，导致后续业务逻辑上会出现一些问题。

之前开发人员在解决这个问题上采用了“线程取消”机制，在主线程Join子线程前调用pthread_cancel取消了子线程。但由于对线程取消机制理解的不透彻，导致子线程在pthread_cond_wait这个"cancellation point"（man cancellation）上退出。在Sun官方文档中提到在pthread_cond_wait这个取消点退出线程时，线程仍然持有与条件变量关联的那把互斥锁，这样就会导致其他进程在上锁时挂起在互斥锁上。但由于我们在代码中使用了不可移植的死锁恢复机制，这个问题也就不那么明显，偶尔出现（锁状态不一致很可能会导致死锁恢复机制失效），就这个偶尔出现导致了上述问题。

与另外一个产品线的同事做了一下内部沟通，发现他们那边的产品已经做了改善（或许是我们没有经常性同步库代码导致代码出现不一致了^_^）。最初他们通过调用pthread_cleanup_push注册取消点清理程序来完成mutex的unlock，该问题得到了暂时解决。但是子线程在其内部其他取消点的退出也带来的一些麻烦，比如open日志文件时。为了控制子线程在合适的取消点退出，他们采用了Disable Cancel State的线程设置，并在关键路径上使用“enable cancel -> pthread_testcancel -> disable cancel”来设置子线程退出的窗口。

另外为了子线程能在主线程Cancel它的时候有机会被唤醒，主线程在cancel调用后，使用pthread_cond_broadcast给子线程提供了一次机会。当然这也让阻塞在同一个条件变量上的其他线程被“假唤醒”，但这种情况是可以被忍受的。

在很多讲解多线程的书籍中都不建议使用cancel机制，这里也建议慎用。直到目前也许还有一些例外情况我们还没能考虑周全呢。