最近真是忙的昏头转向,再加上天气逐渐转冷,很是有些不爽。今天dreamhead提醒我好久不更新Blog了,我也想更新,但是写点什么呢,工作相关的吧。

今天抽出一点儿时间来改一个系统的大Bug,这个问题早已定性,只是由于修改工作量较大,范围较广,而不敢轻易修改。不过眼看系统要上线测试,不改也不行了。

问题主要是由于系统锁资源使用不当,导致有时一些指针在无锁保护的情况下’裸奔’,解决方案就是在业务一层加锁,将底层的接口实现替换为无锁。在修改的过程中常常会遇到这样的情况:

rv = action1
 if (rv != X_SUCCESS) {
  return xx; 
 } 

rv = action2
 if (rv != X_SUCCESS) {
  return xx; 
 } 

action1和action2是需要在锁保护下的两个操作,对于上面的代码在任何一个可能退出该函数的出口,我们都需要进行解锁操作,所以一般方法就是:

locked;

rv = action1
 if (rv != X_SUCCESS) {
  unlocked;
  return rv; 
 } 

rv = action2
 if (rv != X_SUCCESS) {
  unlocked;
  return rv; 
 } 

unlocked
return rv;

这时候一旦还有更多的action或者是嵌套actions,代码维护起来就很是不方便,比如:
rv = action1
 if (rv != X_SUCCESS) {
  if (….) {
   ….
  } else {
   ….
  }
  
 } 

rv = action2
 if (rv != X_SUCCESS) {
  return rv;
 } else {
  rv = action3
   if (rv != X_SUCCESS) {
    return rv;
   }
 }  

return rv;

这时候我们会想到在一个’关键路径’上加上解锁操作即可,这段代码在离开该函数前必将被执行,锁资源也必将被释放,而实现这种方式的一个好的方法就是使用goto,我们看一下用goto后的代码。
locked;

rv = action1
 if (rv != X_SUCCESS) {
  goto over; 
 } 

rv = action2
 if (rv != X_SUCCESS) {
  goto over;
 } 

over:
 unlocked
 return rv;
看起来的确简单直观,逻辑清晰,整个函数就唯一出口。有人说goto不好,影响程序的结构化,其实goto很好,关键要看你如何用,滥用当然不好,像那种从前goto到后面,在从后面goto回来的代码是极力不推荐的。记得刚入司时只是教条的记得书本上说不要使用goto,甚至有的C编码规范’三令五申’不许使用goto,看了公司的代码中居然大量使用goto,当时感到不解,在以后的工作中渐渐体会到goto也有它的好处。任何事物都有其两面性,关键看你如何对待了。

饿了!回去煮面吃 - 肉酱面:)

© 2006, bigwhite. 版权所有.

Related posts:

  1. 恼人的'素数回文'
  2. APR源代码分析-网络IO篇
  3. 理解Zombie和Daemon Process
  4. 也谈字节序问题
  5. 线程函数参数引发的问题