亚洲视频在线播放,美女国产一区,欧美三级小说

C++ 局部静态初始化不是�U�程安全的！

lymons — Sun, 01 Aug 2010 05:19:00 GMT

��h��?C++ 局部静态初始化不是�U�程安全!

http://blogs.msdn.com/b/oldnewthing/archive/2004/03/08/85901.aspx

8 Mar 2004 7:00 AM

在块作用域中的静态变量的规则 (与之相对的是全局作用域的静态变�? �? �E�序�W�一�ơ执行到他的声明的时候进行初始化.

察看下面的竞争条�?

int ComputeSomething()
{
   static int cachedResult = ComputeSomethingSlowly();
   return cachedResult;
}

�q�段代码的意图是在该函数�W�一�ơ被调用的时候去计算一些费�? �q�且把结果缓冲�v来待函数��来再被调用的时候则直接�q�回�q�个值即�?

�q�个基本技巧的变种,在网�l�上也被叫做避免 "static initialization order fiasco". ( fiasco�q�个�?在这个网��上有非常棒的描�q?因此我徏议大家去��M��ȝ��后去理解�?)

�q�段代码的问题是非线�E�安全的. 在局部作用域中的静态变量是�~�译时会在编译器内部转换成下面的样子:

int ComputeSomething()
{
  static bool cachedResult_computed = false;
  static int cachedResult;
  if (!cachedResult_computed) {
     cachedResult_computed = true;
     cachedResult = ComputeSomethingSlowly();
  }
  return cachedResult;
}

现在竞争条�g��比较容易看��C��.

假设两个�U�程在同一时刻都调用这个函�? �W�一个线�E�在执行 cachedResult_computed = true �? 被抢�? �W�二个线�E�现在看到的 cachedResult_computed 是一个真�? true ),然后��q��q�了if分支的处�?最后该函数�q�回的是一个未初始化的变量.

现在你看到的东西�q�不是一个编译器的bug, �q�个行�ؓ C++ 标准所要求�?

你也能写一个变体来产生一个更�p�糕的问�?

class Something { ... };
int ComputeSomething()
{
   static Something s;
   return s.ComputeIt();
}

同样的在�~�译器内部它会被重写 (�q�次, 我们使用C++伪代�?:

class Something { ... };
int ComputeSomething()
{
  static bool s_constructed = false;
  static uninitialized Something s;
  if (!s_constructed) {
      s_constructed = true;
      new(&s) Something; // construct it
      atexit(DestructS);
  }
  return s.ComputeIt();
}
// Destruct s at process termination
void DestructS()
{
   ComputeSomething::s.~Something();
}

注意�q�里有多重的竞争条�g. ��像前面所说的, 一个线�E�很可能在另一个线�E�之前运行�ƈ且在"s"�q�没有被构造前��׃��用它.

甚至更糟�p�的情况, �W�一个线�E�很可能在s_contructed 条�g判定之后,在他被设�|�成"true"之前被抢�? 在这�U�场合下, 对象s��׃��?span style="font-weight: bold;">双重构�?/span>�?span style="font-weight: bold;">双重析构.

�q�样��׃��是很�?

但是�{�等, �q��ƈ不是全部, 现在(原文是Not,我认为是Now的笔�?看看如果�?span style="font-style: italic;">两个�q�行期初始化局部静态变量的话会发生什�?

class Something { ... };
int ComputeSomething()
{
static Something s(0);
static Something t(1);
return s.ComputeIt() + t.ComputeIt();
}

上面的代码会被编译器转化��Z��面的伪C++代码:

class Something { ... };
int ComputeSomething()
{
  static char constructed = 0;
static uninitialized Something s;
if (!(constructed & 1)) {
constructed |= 1;
new(&s) Something; // construct it
atexit(DestructS);
}
static uninitialized Something t;
if (!(constructed & 2)) {
constructed |= 2;
new(&t) Something; // construct it
atexit(DestructT);
}
return s.ComputeIt() + t.ComputeIt();
}

��Z��节省�I�间, �~�译器会把两�?x_constructed" 变量攑ֈ�一�?bitfield �? 现在�q�里在变�?construted"上就有多�?span style="font-weight: bold;">无内部锁�?/span>的读-�?存操�?

现在考虑一下如果一个线�E�尝试去执行 "constructed |= 1", 而在同一旉��另一个线�E�尝试执�?"constructed |= 2".

在x86�q�_��? �q�条语句会被汇编�?/p>

  or constructed, 1
...
or constructed, 2

�q�没�?"lock" 前缀. 在多处理机器�? 很有可能发生两个存储都去��d��一个旧值�ƈ且互�怋�用冲�H�的��D��行碰�?clobber).

�?ia64 �?alpha�q�_��? �q�个��撞��更加明�?因�ؓ它们么没有这��L��?�?�?/span>的单条指�? 而是被编码成三条指��o:

  ldl t1,0(a0)     ; load
addl t1,1,t1     ; modify
stl t1,1,0(a0)   ; store

如果�q�个�U�程�?load �?store之间被抢�? �q�个存储的值可能将不再是它曄��要写入的那个�?

因此,现在考虑下面�q�个有问题的执行��序:

�U�程A 在测�?"constructed" 条�g后发��C��是零, �q�且正要准备把这个��D��定成1�Q?但是它被抢占�?
�U�程B �q�入同样的函�? 看到 "constructed" 是零�q��l�去构�?"s" �?"t", ��d��?"constructed" �{�于3.
�U�程A �l�箋执行�q�且完成它的 �?�?�?的指令序�? 讑֮� "constructed" �?1, 然后构�?"s" (�W�二��?.
�U�程A 然后�l�箋��L��?"t" (�W�二��? �q�设�?"constructed" (最�l? �?3.

现在, 你可能会认�ؓ你能用��界区 (critical section) 来封装这个运行期初始化动�?

int ComputeSomething()
{
EnterCriticalSection(...);
static int cachedResult = ComputeSomethingSlowly();
LeaveCriticalSection(...);
return cachedResult;
}

因�ؓ你现在把�q�个一�ơ初始化攑ֈ�了��界区里面,而��它线�E�安�?

但是如果从同一个线�E�再一�ơ调用这个函��C��怎样? ("我们跟踪了这个调�? 它确实是来自�q�个�U�程!") 如果 ComputeSomethingSlowly() 它自己间接地调用 ComputeSomething()��׃��发生�q�个状况.

�l�论: 当你看见一个局部静态变量在�q�行期初始化�? 你一定要��心.

lymons 2010-08-01 13:19 发表评论

lymons — Sat, 17 Jul 2010 04:17:00 GMT

在C++下编写synchronized method比较�?(1)

在Java中有叫做synchronized�q�样一个方便的关键字。��用这个关键字的话,��可以像下面那样能够��单的�q�行"同步"method. 然�?被同步的method�q�不表示它就能在多线�E�中同时被执�?

public class Foo {    
     public synchronized boolean getFoo() { 
          
     }

那么、在C++ (with pthread)中如何能实现同样的功能呢? 首先,有一个最��单的�Ҏ��是下面�q�个.

// �Ҏ�� a
void Foo::need_to_sync(void) {  
static pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;  
pthread_mutex_lock(&mutex);  
// 临界区处�?nbsp; 
pthread_mutex_unlock(&mutex);  
return;
}

�q�个�Ҏ��, 暂且不说C语言, ��是在C++中下面的若干问题

在��界区中间被return出来
在��界区中间发生异常exception

发生的场�? mutex没有被解锁unlock。我们可以像下面代码那样对这点进行改�q?

// �Ҏ�� b
class ScopedLock : private boost::noncopyable {
public:  explicit ScopedLock(pthread_mutex_t& m) : m_(m) {
    pthread_mutex_lock(&m_);
  }
  ~ScopedLock(pthread_mutex_t& m) {
    pthread_mutex_unlock(&m_);
  }
private:
  pthread_mutex_t& m_;
};

void Foo::need_to_sync(void) {
  static pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
  {
    // 虽然不加�q�个括号�E�序也没有问题�?/span>
    ScopedLock lock(mutex);

    // 在此处添加处�?/span>
  }
  return;
}

OK。return和异常的问题��可以解决了. 但是, 上面�q�没有完全解册��个问�?仍然有下面这个问�?

使用�q�个pthread_mutex_t�q�不是C++�?特别是存在下面的问题:
- 不能和其他的Mutex�c�d��做同��L��处理
- 与其他的Mutex�c�d��使用同一个ScopedLock�c?则不能lock
Java的synchronized�Ҏ��虽然可以"递归lock", 但是上面的代码�ƈ不是�q�样. 在��界区中递归调用自己的话��׃��发生死锁.

特别�?�W?点的递归lock的问题是很重要的. �q�里好好��C��用glibc扩展的话��可以象下面那样解决.

/ �Ҏ�� c

void Foo::need_to_sync(void) {
  static pthread_mutex_t mutex = PTHREAD_MUTEX_RECURSIVE_INITIALIZER_NP;

从NP*1�q�个后缀名就知道, �q�个�Ҏ��没有可移植�? 必须使用pthread_mutex_init来初始化递归mutex,而pthread_mutex_init函数在一个线�E�中只能被调用一��? 如果惌��用synchronized method的方法来实现�q�个的话,��变成了"是先有鸡�q�是先有�?的话题了. 所�?用叫做pthread_once的函数来实现�?�q�也�?a >在SUSv3中被记蝲的定�?/a>�?/p>

// �Ҏ�� d

namespace /* anonymous */ {
  pthread_once_t      once = PTHREAD_ONCE_INIT;
  pthread_mutex_t     mutex;
  pthread_mutexattr_t attr;

  void mutex_init() {
    pthread_mutexattr_init(&attr);
    pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_RECURSIVE);
    pthread_mutex_init(&mutex, &attr);
  }
}

void Foo::need_to_sync(void) {
  pthread_once(&once, mutex_init);

  {
    ScopedLock lock(mutex);

    // 処理

  }
  return;
}

上面的代码就OK了�?/p>

�q�就能够解决递归lock的问题了.但是..., �q�个�Ҏ��

�q�越来越不像C++的代码了.。对每一个想要同�?synchronize)的方法都像这么样写代码的�?效率变得非常低下.
随机成本大。速度慢�?

��׃��产生上面那样的新问题.

�?/span>[C++] 在C++下编写synchronized method比较�?2)

"�? �Ҏ��的同步应该是�l�常必需�? �q�不是没有方便的办法",�q�样的说法也有吧. 是的, �? 一般的办法是下面那�?

做成一个Mutex,作�ؓ(non-POD型的, ��x��通的)C++�c?
做成一个Mutex�cȝ��实例,作�ؓ�c�d��? 或者是全局变量, 来同步化�Ҏ��

来看看它的具体实现吧. 首先做成的Mutex�c�L��下面那样*2�?/p>

class Mutex {
public:
  Mutex() {
    pthread_mutex_init(&m_, 0);
  }
  void Lock(void) {
    pthread_mutex_lock(&m_);
  }
  void Unlock(void) {
    pthread_mutex_unlock(&m_);
  }
private:
  pthread_mutex_t m_;
};

现在的Mutex�c?被作为抽象基�c?接口�c?的场合也比较�? 在这里就不说�? ScopedLock�c�M��需要有若干的修�? 想下面那样写��好.

template<typename T> class ScopedLock {
public:
  ScopedLock(T& m) : _m(m) {
    _m.Lock();
  }
  ~ScopedLock() {
    _m.Unlock();
  }
private:
  T& _m;
};

用这个Mutex�c�L��同步�Ҏ��, ��可以像下面那样�? 首先是看看一个明昄��有错误的例子.

// �Ҏ��e

void Foo::need_to_sync(void) {
  static Mutex mutex;
  {
    ScopedLock<Mutex> lock(mutex);

    // 処理

  }
  return;
}

�q�是... 代码虽然��单易�?但是很遗�?它不能很好工�? NG!. Foo::need_to_sync函数�W�一�ơ被执行的时候如果恰好是多个�U�程同时执行的话, mutex 的构造函数就有被多次调用的可能�?关于理由�Q�可以参考微软中比较有名气的blog文章The Old New Thing�?a C++ scoped static initialization is not thread-safe, on purpose!"在这里面有详��的描述�Q�所以就我们��׃��在详�l�叙�q�C��*3。在�q�篇blog里��用了VC++的代码作��Z��子，但是g++也是差不多的。所�?strong>“动态的初始化局部的静态变�?#8221;是，在线�E�所完全意识不到的情况下�q�行�?span class="footnote">*4�?/p>

接下来，要介�l�一个在目前做的比较好的�Ҏ��?��Z��单我们��用了全局变量�Q�但是即使作为类变量�Q�类中的static成员变量�Q�也是一��L��。这个方法就是��?#8220;非局部的静态变�?#8221;来做成Mutex�?/p>

// �Ҏ��f

namespace /* anonymous */ {
  Mutex mutex;
}

void Foo::need_to_sync(void) {
  ScopedLock<Mutex> lock(mutex);

  // 处理

  return;
}

�q�个是最��行的方法，而且基本上可以没有问题就能工作得很好�?/p>

在一个全局的类对象x存在�Q�且在x的构造函��C��直接或者绕弯间接的调用Foo::need_to_sync函数的场合，会引起一些问题。也��是静态的对象的初始化��序的问题，�q�个问题一般也被叫�?static initialization order fiasco" 。在执行到mutex的构造函��C��前， mutex.Lock()有可能会被执行�?/p>

�q�里的FAQ�?0.12�?0.16*5、在里面对自��q��代码的初始化��序已经证明了没有问题，而且��来也不会出现问题，所以上面的�Ҏ��是OK的�?/p>

如果�Q?初始化顺序的问题不能保证他没有问题的话，只好使用pthread_once�?#8220;�Ҏ��d”�Q�或者移植性低�?#8220;�Ҏ��c”。我的个人感觉是�Ҏ��c�q�是比较不错的选择�?/p>

在最后我们尝试考虑一下如何把�Ҏ��c变成C++的代码�?/p>

// �Ҏ��c (重新讨论)

void Foo::need_to_sync(void) {
  static pthread_mutex_t mutex = PTHREAD_MUTEX_RECURSIVE_INITIALIZER_NP;

目标是�?/p>

隐藏pthread_mutex_t�c�d��、让自己写的�cȝ��c�d��可见�?
在方法e,f中像使用ScopedLock模板那样�q�行修改�?

当然�Q�不让它发生初始化顺序的问题�?br>

�?/span>[C++] 用C++�~�写synchronized method比较�?(3)

�q�是�Ҏ��c的改良�?首先�Q?��Z��避免发生初始化顺序的问题�Q?必须是不允许调用构造函数就能完成对象的初始化。因此，必须像下面那样初始化mutex对象

// �Ҏ��c' (假设)

void Foo::need_to_sync(void) {
  static StaticMutex mutex = { PTHREAD_MUTEX_RECURSIVE_INITIALIZER_NP, ........ };

一般的不允许像�q�样初始化C++�c�R��ؓ了实��C��面那��L��初始化，StaticMutex�c�d��L��POD型的。所谓POD型就是，

不允许有构造函�?
不允许有析构函数
不允许编译器生成拯��构造函敎ͼ� 赋值构造函数�?
不允许有private, protected 的成�?
不允许有虚函�?

满��以上规格的类�?span class="footnote">*6�?/p>

大概有严格的制约,但是利用"定义非虚成员函数是没有问题的"�q�个�Ҏ�? 我们��试改良�Ҏ��c的方�?

...像下面那样如�?

// �Ҏ��c'

#define POD_MUTEX_MAGIC 0xdeadbeef
#define STATIC_MUTEX_INITIALIZER           { PTHREAD_INITIALIZER,              POD_MUTEX_MAGIC }
#define STATIC_RECURSIVE_MUTEX_INITIALIZER { PTHREAD_RECURSIVE_INITIALIZER_NP, POD_MUTEX_MAGIC }

class PODMutex {
public:
  void Lock() {
    assert(magic_ == POD_MUTEX_MAGIC);
    pthread_mutex_lock(&mutex_);
  }
  void Unlock() {
    assert(magic_ == POD_MUTEX_MAGIC);
    pthread_mutex_unlock(&mutex_);
  }
  typedef ScopedLock<PODMutex> ScopedLock;

public:
  // 虽然�~�程了POD�? 但是不定义成public���是无效�?/span>
  pthread_mutex_t mutex_;
  const unsigned int magic_;
};

// ScopedLock�c�L��板是留用了在�Ҏ��e,f中做成的代码.

void Foo::need_to_sync(void) {
  static PODMutex mutex = STATIC_RECURSIVE_MUTEX_INITIALIZER;
  {
    PODMutex::ScopedLock lock(mutex);

    // 处理.

  }
  return;
}

上面的代码满��了"隐藏了pthread_mutex_t�?留用了ScopedLock<>"�q�两个目�? �q�不��是有点儿像C++的代码了�? �q�有,PODMutex�c�d��是即使在上记例子中那��L��局部静态变量以�?也能攑ֿ�的��用全局变量,�c�d��量了.

而且, 成员变量 magic_ �? 一个const成员变量, 所以当使用�~�译器自动生成的构造函数来创徏一个对象时��׃��发生错误. 因此,在构建release版程序时把它剔除��好�?

使用g++ -S来编译上面的代码, 生成汇编代码. 我们��p��看见下面那样的局部的静态变�?

$ g++ -S sample.cpp
$ c++filt < sample.s | lv
(�?
        .size   Foo::need_to_sync()::mutex, 28
Foo::need_to_sync()::mutex:
        .long   0
        .long   0
        .long   0
        .long   1
        .long   0
        .long   0
        .long   -559038737

0,0,0,1,0,0 �q�样的东西是 PTHREAD_RECURSIVE_INITIALIZER_NP , -559038737 则是 POD_MUTEX_MAGIC 。即使没有进行动态的初始�?不调用构造函�?、仅仅是在目标文件上生成的目标代码那��L��q�行静态初始化, mutex对象也能被正常的初始�? 所以这�D�代码是OK�?

随便, 在��用boost库的场合, �Ҏ��f之外的选择余地几乎没有(臛_��是现�?. 一看见ML�{? (当然!!)��q��道可能会出现 order��序的问�? 但是, ��q��前来�? 既要保证既要保证可移植�?a title="Windowsはどうする？という命��を解決できないのかもしれません - 推測" name="20040713fn7">*7和速度,又要能做成与�Ҏ��c相当的PODMutex的方法好像还没有出现�?

完结

*1�Q�non portable 的意�?/p>

*2�Q�递归mutex的例子的代码太冗长了,�q�里��q��?�? �Ҏ��pthread_mutex_init来进行初始化,��׃��得做成递归mutex变得比较�Ҏ��?

*3�Q�这里记载了 g++ -S的结果和解说

*4�Q?005/12�q�记: 在最�q�的g++中发生异常、参照这�?http://d.hatena.ne.jp/yupo5656/20051215/p2

*5�Q�日语文�?ASIN:489471194X 中记载着��译�? �q�有 static initialization order 的问�?在此处也有一些记�?

*6�Q�详�l�是参看 ISO/IEC 14882:2003 或者是 JIS X 3014:2003 的�?#167;3.9/10 C互換型」�?#167;8.5.1/14 静的�a�憶期間をもつC互換型の集成体の波括弧で囌ӂ�だ初期化子並た끫よる静的な初期化」�?#167;9/4 C互換構造体」这几个章节

*7�Q�Windows是如何做�? 可能不能解决�q�个命题 - 推测

http://d.hatena.ne.jp/yupo5656/20051215/p2

http://d.hatena.ne.jp/yupo5656/20041011#p1

http://blogs.msdn.com/b/oldnewthing/archive/2004/03/08/85901.aspx

http://d.hatena.ne.jp/yupo5656/20071008/p1

lymons 2010-07-17 12:17 发表评论

lymons — Tue, 13 Apr 2010 02:29:00 GMT

摘要: W2K信号(Signals)的设备驱�?

Unix下的信号提供了一个简单的IPC机制�Q�也��是当进�E�收��C��个信号后会异�?asynchronous) 地调用你的信号处理函�?也叫做句�?�Q�不��你的代码是否已�l�处在执行的�q�程之中�?而在Windows 2000(译者注�Q�版本高于W2k的Windows�q�_��)下就需要用��C��个设备驱动，以便你能使用异步�q�程调用(asynchronous procedure calls , ��U�APCs或者APC) 来达成同��L��效果.

By Panagiotis E.
August 01, 2001
URL:http://www.ddj.com/windows/184416344

��译�Q�Lymons (lymons@gmail.com)
阅读全文

lymons 2010-04-13 10:29 发表评论

设计模式在Linux文�g�pȝ��中的��单实�?

lymons — Mon, 02 Feb 2009 05:08:00 GMT

摘要: From 2008�_�N�? 设计模式在Linux文�g�pȝ��中的��单实�?注：�q�边文章是�ؓ了学习设计模式而写的，�q�不��h��实际的意义。仅仅作为学习设计模式的一个参考�?Linux中的文�g�pȝ��Q�设备驱动，和实际设备间的结构关�p�d��下图所�C�：用户对设备上的数据进行I/O讉K��Q�都要先把I/O��h��传递到VFS层，然后再通过实际的文件系�l�，最�l�传递到讑֤�的驱... 阅读全文

lymons 2009-02-02 13:08 发表评论

lymons — Mon, 02 Feb 2009 04:54:00 GMT

摘要: Kernel Korner - ATA Over Ethernet: 把硬盘放到局域网�? ATA Over Ethernet: 把硬盘放到局域网�? By Ed Cashin ��译:Lymons Lau Created 2005-04-28 01:00 随着ATA��盘比�v��带�q�样的存储设备来是越来越便宜�Q�一些简单的新存储技术能使你为存档，备䆾或者现场应用徏... 阅读全文

lymons 2009-02-02 12:54 发表评论

用lex/yacc来解析配�|�文�?

lymons — Mon, 02 Feb 2009 04:31:00 GMT

摘要: From 2008�_�N�? 在linux�q�_��下的较�ؓ庞大的命令一般都带有一个配�|�文�Ӟ��用于存储该命令启动时要设�|�的参数�Q�用戯��可以变更该配�|�文件中的某些域的倹{��因此，在命令中��p��考虑怎么来存取这些文仉��的倹{��一般情况下�Q�大多数�E�序员都愿意自己�~�写一�D늨�序来解析配置文�g里内容，在配�|�文件比较小的情况下�Q�该中方法也非常方便适用�Q�我�q�x��也喜�Ƣ这么作。但是，当在配置�?.. 阅读全文

lymons 2009-02-02 12:31 发表评论

RX-RPC的客��L��与服务器端的通信解析

lymons — Mon, 02 Feb 2009 03:58:00 GMT

摘要: From 长城 RX-RPC的客��L��与服务器端的通信解析 Rx是扩展远�E�过�E�调用（Extended Remote Procedure Call�Q�的�~�写�Q�顾名思义�Q�它��是RPC协议的一个扩展。与之不同的是，它允�怓Q意大��的数据��h��以及�l�端到端�Q�end-to-end�Q�的认证和安全提供了通用支持。另外，�q�个协议能��允许客户端和服务器端自适应它们兌��性能... 阅读全文

lymons 2009-02-02 11:58 发表评论

Linux中处理来自共享对象的同步事�g

lymons — Mon, 02 Feb 2009 03:28:00 GMT

摘要: September 28, 2007 Linux中处理来自共享对象的同步事�g By lymons Linux中处理来自共享对象的同步事�g 怎么利用设计模式来更有效的��用共享内�? �U�别�Q�中�{? ... 阅读全文

lymons 2009-02-02 11:28 发表评论

lymons — Sun, 01 Feb 2009 07:54:00 GMT

摘要: 「Code Reading―从开源里学习软�g开发的技法」有�q�样一本书。我是这本书日本版的译者，呵呵有点王婆卖瓜---自卖自夸的感觉，但是把读源代码作��Z��题的在市面还没有其他的书。我认�ؓ�q�是一本网�|�了从技法到工具�Q�数据结构，构架�Q�还有利用代码的实际��L��的实例的好书�?

照片1●「Code Reading―跟着开源来学习软�g的开发技法�?
　�q�本书的前言里，�~�程高手Dave Thomas写下了下面的话�?
　没有研读�q�其他作家作品的伟大作家�Q�没有研�I�过其他��d��W�法的伟大画�Ӟ��没有盗取�q��ƈ肩作战的同事的技术的技巧高明的外科�ȝ��Q�没有在副驾驶的位置�U�篏实际�l�验的�L�?67的机长，在现实生�z�M��真的会存在他们这��L��人吗�Q?nbsp; 阅读全文

lymons 2009-02-01 15:54 发表评论

准则6�Q�遵守多�U�程�~�程的常识（下）

lymons — Sun, 01 Feb 2009 07:41:00 GMT

From 2008�_�N�?/a>

UNIX上C++�E�序设计守则(6)

准则6: 遵守多线�E�编�E�的常识

要准��把握在POSIX标准的函��C��Q�那些函数是非线�E�安全的�Q�一定不要��?
要让自己�~�写的函数符合线�E�安�?

在访问共享数�?变量之前一定要先锁�?
如果使用C++的话�Q�一定要注意函数的同步方�?

说明: (2) 要让自己�~�写的函数符合线�E�安�?/p>

在写多线�E�的应用�E�序�?在多个线�E�里�׃�n的变量要先锁定然后在更新�?。那么在多线�E�里�׃�n的变量主要有全局变量和函数内的静态变量。而且,即��是short型和int型的�׃�n变量也要先锁定后更新才能保证其安全�?/p>

�?详细的是参�?

�q�有,在��用C++�~�程的场合要注意函数的方步方法。一般的说来下面的写法是错误的�?strong>Mutex在函数内被声明成静态变量是不允许的�?/p>

int incr_counter(void) {
  static Mutex m;  // �q�么写不�?br>  m.Lock();

  static int counter = 0;
  int ret = ++counter;

  m.Unlock();
  return ret;
}

应该用下面的方式来代�?

Mutex m;

int incr_counter(void) {
  m.Lock();
  // ...

把Mutex声明成全局变量的话比较�?�E�微比上一个好)�?/p>

�?详细是参�?

UNIX上C++�E�序设计守则(6)-- 补记

�U�程安全函数是像下面那样

不要操作局部的静态变�?函数内的static型的变量)和非局部的静态数�?全局变量)。�ƈ�?其它的非�U�程安全函数不要调用
要操作这��L��变量的话, ��p��使用mutex�q�行同步处理,来限制多个线�E�同时对它进行操�?

被定义的,但是

特别是前�? 和被叫做可重入的(reentrant)函数有区�?
反之, 后者特别是和叫�?Serializable"(不单单是MT-Safe)"Safe"的函数有区别

也有以上的情��c��在Solaris的man手册�? 用后者的方式�q�行区别. 从多�U�程�E�序里安全调用的�?��叫�?Safe", 而且, 在多�U�程中能够�ƈ�?concurrency)地执行这个函数的处理的话,好像��叫�?MT-Safe"�?/p>

�? 因�ؓ比较详细�? 如果不是在对于执行速度要求比较苛刻的环境中�~�写代码的话, 单单地意识到「是否线�E�安全」就��_��?不是吗�?/p>

lymons 2009-02-01 15:41 发表评论

准则6�Q�遵守多�U�程�~�程的常识（上）

lymons — Mon, 29 Dec 2008 09:11:00 GMT

From 2008�_�N�?/a>

UNIX上C++�E�序设计守则(6)

准则6: 遵守多线�E�编�E�的常识

要准��把握在POSIX标准的函��C��Q�那些函数是非线�E�安全的�Q�一定不要��?
要让自己�~�写的函数符合线�E�安�?

在访问共享数�?变量之前一定要先锁�?
如果使用C++的话�Q�一定要注意函数的同步方�?

说明: (1) 要准��把握那些非�U�程安全的函敎ͼ�一定不要��?/p>

如果在POSIX�q�_��上进行多�U�程�~�程�Ӟ��有几个最基本的知识，也就是所说的“常识”�Q�希望大家一定要严格遵守�?/p>

...首先、我们要理解“�U�程安全”的意思。线�E�安全的函数��是指，“一个能被在多个�U�程同时调用也不会发生问题的函数”。这��L��函数通常要满��以下几个的特质�?/p>

不要操作局部的静态变�?函数内的static变量)和全局静态数�?全局变量�Q�函数外的静态变�?。而且�Q�也不要调用其他的非�U�程安全的函�?
如果要操作这��L��变量的话�Q�事先必��M��用互斥锁mutex�q�行同步�Q�否则一定要限制多个�U�程同时对它的访�?

那么、在POSIX标准的函数里面，也有不满��上�q�条件的。由于历史遗留问题，一些函数的识别标识(signature)的定义没有考虑到线�E�安全的问题�Q�所以不��怎么做都不能满��上述的条件。例如，看看 localtime函数吧。它的定义的识别标识�Q�signature�Q�如下：

struct tm *localtime(const time_t *timer);

localtime 函数是，把一个用整数形式表示的时�?�?970/1/1到现在�ؓ止的�U�数)、�{换成一个能让�h�Ҏ��明白的年月日形式表示出来的tm�l�构体�ƈ�q�回�l�调用者的函数。根据规��D��明、返回出来的tm�l�构体是不需要free()掉，也不能释攄��。这个函数典型的实现��像下面的代码那��P��

struct tm *localtime(const time_t *timer) {
  static struct tm t;
  
  /* ... 从timer参数里算出年月日�{�数�?... */

  t.tm_year = XXX;
  /* ...把它们填入到�l�构体内... */
  t.tm_hour = XXX;
  t.tm_min  = XXX;
  t.tm_sec  = XXX;

  return &t;
}

�q�个函数如果被像下面那样使用的话�Q�就会有漏洞�Q?/p>

在线�E�A里执�?ta = localtime(x);

在线�E�B里执�?tb = localtime(y);

�U�程A参照ta�l�构体里的数�?→ ��发现这些数据是一些奇怪的��|��

...在函数的说明手册里对�q�个问题也没有做�q�详�l�的说明。关于这个漏�z�，在localtime函数即��使用了mutex锁也不能被回避掉。所以，�q�个函数定义的识别标识是不行滴�?br>[译者lymons注：在多个线�E�里调用localtime函数之所以有问题的原因是�Q�localtime函数里返回的tm构造体是一个静态的�l�构体，所以在�U�程A里调用localtime函数�Ӟ��该结构体被赋予正��的��|��而在�U�程A参照�q�个�l�构体之前，�U�程B又调用localtime的话�Q�这个静态的�l�构体又被赋予新的一个倹{��因此在�U�程A对这个结构体的访问都是基于一个错误的��D��行的]

正因为如此，��像上面说过的POSIX规格(SUSv3)里整齐的

asctime, basename, catgets, crypt, ctime, dbm_clearerr, dbm_close, dbm_delete, dbm_error, dbm_fetch, dbm_firstkey, dbm_nextkey, dbm_open, dbm_store, dirname, dlerror, drand48, ecvt, encrypt, endgrent, endpwent, endutxent, fcvt, ftw, gcvt, getc_unlocked, getchar_unlocked, getdate, getenv, getgrent, getgrgid, getgrnam,

(省略)

对于在规��g��被定义�ؓ非线�E�安全的函数�Q�应该制定一个避免��用它们的规则出来�Q��ƈ且制作一个能够自动检查出是否使用了这些函数的开发环境，应该是比较好的�?/p>

反之�Q�在�q�里没有被登载的POSIX标准函数都被假定�?"shall be thread-safe" 的、所以在实际的��用中可以认�ؓ在多�U�程环境里是没有问题�?而且在��用的�q�_��上没有特别地说明它是非线�E�安全的�?�?/p>

另外�Q�有几个非线�E�安全的函数�Q�都准备了一个备用的�U�程安全版本的函�?仅仅是变更了函数的识别标�?。像�q�些函数��Z��与原版进行区别都在其函数名后面添加了 _r �q�个后缀 *1。例如，asctime函数��有�U�程安全版本的函数asctime_r。在规格说明中是否定义了备用函数�Q�可以试着点击刚才�?a >那个�|�页里面的函数名��可以看到。点�?rand函数��可以看刎ͼ�

[TSF] int rand_r(unsigned *seed);

用[TSF]�q�样的文字标记出来的函数吧。这��是备用函数。在一览中没有记蝲出来的函�?备注�Q?�E�微有点儿出入。请参照�q�里)、据我所知还有下面的备用函数�?/p>

asctime_r, ctime_r, getgrgid_r, getgrnam_r, getpwnam_r, getpwuid_r, gmtime_r, localtime_r, rand_r, readdir_r, strerror_r, strtok_r

�q�有�Q�在规格以外�Q�还准备了很多的下面那样的函数�?/p>

gethostbyname_r, gethostbyname2_r

在最�q�的操作�pȝ��中、也使用 getaddrinfo API函数来解决IPv6名字对应的问题。gethostbyname�p�d��的API都是比较陈旧的函��C��、所以��用前面的函数�q�是比较好吧*2。根据规格SUSv3�Q�getaddrinfo也是�U�程安全的：

The freeaddrinfo() and getaddrinfo() functions shall be thread-safe.

在多�U�程�~�程中，不要使用非线�E�安全的函数�Q�而他们的备用函数可以攑ֿ�地积极的��M��用�?/p>

→后箋

*1�Q�在C�a�語里函数不能重蝲�Q�所以只能添加一个新的函�?/p>

*2�Q�跟�|�络有关的API哪些是新的哪些是旧的�Q�可以参�?IPv6�|�络�~�程 (network technology series) �q�本好书

lymons 2008-12-29 17:11 发表评论

准则5�Q�尽可能避免�U�程的�g�q�撤销处理

lymons — Thu, 25 Dec 2008 06:08:00 GMT

From 2008�_�N�?/a>

[C++] UNIX上C++�E�序设计守则(5)

准则5: ��可能避免线�E�中做�g�q�撤销的处�?br>

�U�程的异步撤消是指：一个线�E�发��Z��断其他线�E�的处理的一个动�?
延迟撤消因�ؓ是规��D��由度比较高、所以根据OS和C库函数的版本它也有各式各��L��动作

要想在不同的环境下都能稳定的动作的话�Q�就必须要详�l�调查运行环境和�Q�对C库函数进行抽象化�Q�做必要的条件编�?
在C++中、「撤消发生时的对象释放」的实现不具有可�U�L��?

�U�程撤销要慎重��用。在C++里不要��?

说明:

在前面我们已�l�讲�q�，�U�程的撤消分为「异步」「�g�q�」这两种�c�d��、�ƈ且「异步撤消」也是非常容易引起各�U�复杂问题的元凶�?/p>

那么�Q�现在要在程序中除掉「�g�q�撤消」。�g�q�撤消虽然不会像异步撤消那样会引起各�U�各��L��问题、但是、注意事��还是有很多的。只有把下面的这些注意事��全部都把握之后才能攑ֿ�使用�?/p>

注意事项1: 要好好把握撤消点

和异步撤消不一��L��是、撤消处理一直会被�g�q�到在代码上明示出来的撤消点之后才会被执行。如果编写了一个具有�g�q�撤消可能的代码、代码中的那条语句是撤消炏V��必��要正确的把握�?/p>

首先、调用过pthread_testcancel函数的地方就变成撤消点了。当然这个函数是、仅仅�ؓ了「变成�g�q�撤消」的目的而设�|�出来的函数。除此之外、某些标准库函数被调用后会不会变成撤消点是在规格(SUSv3)中决定的�?a >请参照规��D��?/a>、有下面的函��C��览�?/p>

下面的函�?span style="FONT-WEIGHT: bold">�?/span>撤消�?strong>

accept, aio_suspend, clock_nanosleep, close, connect, creat, fcntl, fdatasync,
fsync, getmsg, getpmsg, lockf, mq_receive, mq_send, mq_timedreceive,
mq_timedsend, msgrcv, msgsnd, msync, nanosleep, open, pause, poll, pread,
pselect, pthread_cond_timedwait, pthread_cond_wait, pthread_join,
pthread_testcancel, putmsg, putpmsg, pwrite, read, readv, recv, recvfrom,
(�?

下面的函�?span style="FONT-WEIGHT: bold">不是撤消�?strong>

access, asctime, asctime_r, catclose, catgets, catopen, closedir, closelog,
ctermid, ctime, ctime_r, dbm_close, dbm_delete, dbm_fetch, dbm_nextkey, dbm_open,
dbm_store, dlclose, dlopen, endgrent, endhostent, endnetent, endprotoent,
endpwent, endservent, endutxent, fclose, fcntl, fflush, fgetc, fgetpos, fgets,
fgetwc, fgetws, fmtmsg, fopen, fpathconf, fprintf, fputc, fputs, fputwc, fputws,
(�?

看到�q�些我想已经明白了、但是在规格中也说明了「能否成为撤消点跟具体的实现相关的函数」也是多数存在的。原因是、�ؓ了可�U�L��性、保证「在一定的旉��内让�U�程的�g�q�撤消完成」是很困隄��事情*1。做的不好的话、只要稍微一提升OS的版本就可能让做出来的程序��品不能动作�?/p>

即��是这样那�q�想要��用�g�q�撤消吗�Q?/p>

注意事项2: 实现要知道cleanup函数的必要�?/strong>

可能被�g�q�撤销的线�E�在�q�行的过�E�中�Q�要甌��资源的场合，一定要考虑��C��下的几点�Q�否则就会编制出含有资源丢失和死锁的软�g产品�?/p>

例如�~�写的下面的函数��׃��能被安全的�g�q�撤销掉�?/p>
void* cancel_unsafe(void*) {
static pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
pthread_mutex_lock(&mutex); // 此处不是撤消�?br> struct timespec ts = {3, 0}; nanosleep(&ts, 0); // �l�常是撤消点
pthread_mutex_unlock(&mutex); // 此处不是撤消�?br> return 0;
}
int main(void) {
pthread_t t;
// pthread_create后马发上收到一个有效的延迟撤消的要�?br> pthread_create(&t, 0, cancel_unsafe, 0);
pthread_cancel(t);
pthread_join(t, 0);
cancel_unsafe(0); // 发生死锁�Q?br> return 0;
}

在上面的样例代码中、nanosleep执行的过�E�中�l�常会触发�g�q�撤销的最�l�动作，但是�q�个时候的mutex锁还处于被锁定的状态。而且、线�E�一被�g�q�撤消的话就意味着没有人去释放掉这个互斥锁�?span class=footnote>*2。因此、在下面的main函数中调用同��L��cancel_unsafe函数时就会引��h��锁了�?/p>

��Z��回避�q�个问题、利用pthread_cleanup_push函数在撤消时释放掉互斥锁的话��OK了，也就不会死锁了�?/p>
// 新增清除函数
void cleanup(void* mutex) {
pthread_mutex_unlock((pthread_mutex_t*)mutex);
}

// �_�体字部分是新增的语�?br>void* cancel_unsafe(void*) {
static pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
pthread_cleanup_push(cleanup, &mutex);
pthread_mutex_lock(&mutex);
struct timespec ts = {3, 0}; nanosleep(&ts, 0);
pthread_mutex_unlock(&mutex);
pthread_cleanup_pop(0);
return 0;
}

注意事项3: 实现要清楚�g�q�撤消和C++之间的兼容度

使用C语言的场合，利用上面的pthread_cleanup_push/pop函数��p��安全地执行�g�q�撤消的动作�Q�但是在C++语言的场合就会出现其他的问题�?strong>C++与�g�q�撤消之间的兼容度是非常差的。具体的表现有以下两个问�?

执行延迟撤消的时候，内存栈上的对象的析构函数会不会被调用跟具体的开发环境有关系
- GCC3版本��׃��会调用�?
- Solaris和Tru64 UNIX下的原生�~�译器的场合�Q�就调用析构函数(好像)
pthread_cleanup_push/pop函数和C++的异常处理机制之间有着怎样的相互媄响也能具体环境有�?

不调用析构函敎ͼ�或者在抛出异常的时候不能做cleanup处理�Q�经常是发生内存泄漏�Q�资源丢失，�E�序崩溃�Q�死锁等现象的原因。��o人意外的是对于这个深层次的问题，��p��Boost C++�?/a>都束手无�{��?/p>

[Q] Why isn't thread cancellation or termination provided?

[A] There's a valid need for thread termination, so at some point Boost.Threads probably will include it, but only after we can find a truly safe (and portable) mechanism for this concept.

先必��ȝ��保对象的自由存储�Q�而后全都让cleanup函数去释攑֯�象的�Ҏ��也有�Q�但是这�ơ是牺牲了异常安全性�?br>�Q�原文没有看明白�Q�オブジェクトを必ずフリヹ{��トア上に��Z��し、解体を全て、クリーミ냊ップハンドラに行わせる手もありますが、今度は例外安全性が犠牲になるでしょう。）

应该说的是，在��用C++的工�E�里不对�U�程�q�行延迟撤消处理�q�是比较实际的�?/p>

*1�Q�好的问题是 gethostbyname()函数

*2�Q�异步撤消跟malloc函数的例子很�怼�

原文地址�Q�http://d.hatena.ne.jp/yupo5656/20040725/p2

lymons 2008-12-25 14:08 发表评论

lymons — Fri, 19 Dec 2008 03:01:00 GMT

From 2008�_�N�?/a>

原文地址�Q�http://d.hatena.ne.jp/yupo5656/20040724/p1

�?/span>[C++] UNIX上的C++�E�序设计守则 (4)

铁则4: 请不要做�U�程的异步撤消的设计

�U�程的异步撤销是指�Q?某个�U�程的执�?span style="FONT-WEIGHT: bold">立刻被其他线�E�给强制�l�止�?
请不要单单�ؓ了让“设计更简�?#8221;或�?#8220;看�v了更��?#8221;而��用线�E�的异步撤消

咋一看还是挺��单的。但是搞不好可能会引起各�U�各��L��问题。请不要在不能把握问题的实质��做��Z��用线�E�的异步撤消的设计！

在pthread的规��D��明中�Q�允�怸�个线�E�可以强制中断某个线�E�的执行。这��是所说的异步撤消�?/p>

�U�程的撤消有下面的两�U�方式�?/p>

方式1�Q?异步撤消(PTHREAD_CANCEL_ASYNCHRONOUS)
- 撤销动作是马上进行的
方式2�Q?延迟撤销(PTHREAD_CANCEL_DEFERRED)
- 撤消动作�Q�是让线�E�的处理一直被延迟到撤消点才会��L��?

�q�有�Q�到底是用哪�U�撤消方式，不是撤消侧，而是被撤销侧能够决定的*1。另外，在被撤销侧也能够选择完全��止撤消的这�U�方�?*2�?/p>

会造成什么问题呢

那么�Q�让我看看�ؕ用线�E�的异步撤消会引起什么问题呢。看�q�准�?的�h可能会知道，在下面的脚本里，被撤销�U�程以外的�Q意一个线�E�会被死锁�?/p>

�U�程1中调用malloc函数正在做内存分配的�q�程中，�U�程2异步撤消了线�E?的处�?
�U�程1马上被撤销�Q�但是malloc函数中的互斥锁就没有�U�程去解除了
后面的�Q意一个线�E�如果再�ơ调用malloc函数的话��׃��马上��D��该线�E�死�?

在这个例子中使用了malloc函数�Q�但是其他的危险函数�q�有很多�?/p>

反之�Q�即使做了异步撤消也没有问题的函��C��有少数存在的、我们把它们叫做「async-cancel safe函数」或者「异步撤消安全函数」。在一些商用UNIX*3中、OS提供的api函数的文档说明中有async-cancel safety的记载、但是在Linux(glibc)里就很遗憾，几乎没有相关的说明�?/p>

在这儿，参看规格(SUSv3)的话�Q�会发现�Q��?a >描述异步撤消安全的函数只�?�?/a>�?/p>

pthread_cancel
pthread_setcancelstate
pthread_setcanceltype

而且、里面还�?No other functions are required to be async-cancel-safe"�q�样的记载。因此，Linux的场合，如果在文��里没有记蝲成async-cancel safety的函敎ͼ�我们�q�是把它假定成不安全的函��Cؓ�?

如何避免�q�些问题�?/h4>
在多�U�程�~�程中�ؓ了安全的使用异步撤消处理、有没有回避死锁的方法呢�Q�我们试着想了几个。他们与准则3里的�U�程+fork的场合的回避�{�很�怼��?/p>

回避�Ҏ��1: 被撤销�U�程中，只能使用异步撤消安全函数

首先�Q�被撤销�U�程中，只能使用异步撤消安全函数。但是这个方�?/p>

在规��D��明中只有3个异步撤消安全的函数
�q�些以外的函数是不是异步撤消安全(商用UNIX)、因为没有说明文��我们不清楚(Linux)

中有以上的两点，所以这个回避方法几乎不现实�?/p>

回避�Ҏ��2: 被撤销�U�程中，在做非异步撤消安全处理的�q�程中，再把撤消方式讄��成「�g�q�」或者是「禁止�?/strong>

�W�二个是�Q�被撤销�U�程在做非异步撤消安全处理的�q�程中，把撤消方式再讑֮�成「�g�q�」或者「禁止」。对于这个方�?/p>

��像�Ҏ��1写的那样、要把我那个函数是异步撤消安全的一时还是挺�ȝ��?
在�Q意的场所�q�不能保证撤消动作会被马上执�?

例如�Q�再讑֮�成「�g�q�」后的一�D�|��间内如果撤消发生时、某个正在阻塞的I/O函数是否能够被解除阻塞还是挺微妙�?
如果讑֮�成撤消禁止的话，则撤消会被屏蔽掉

有上面样的问题、会��D��「一�_�ֿ�设计撤消方式的替换，从一开始就使用延迟撤消�q�不够好」这��L��l�果。所以这几乎是不好的一个回避策�?/p>

回避�Ҏ��3�Q?使用pthread_cleanup_push函数�Q�登录异步撤消时的线�E�数据清除的回调函数

�W�三�U�则是，用pthread_cleanup_push函数、登录一个在异步撤消发生时的数据清除的回调函数。这和在准则3中介�l�的pthread_atfork函数有点儿类伹{��用�q�个函数��d��的回调函数来清除�U�程的数据和锁，��可以回避死锁了�?/p>

...但是�Q�pthread_cleanup_push函数��d��的回调函敎ͼ�在「�g�q�撤消」的场合是不能被调用的。因此、这个回避方法对于异步撤消没有什么大的作用�?/p>

回避�Ҏ��Q�：不要执行异步撤消处理

最后是、不要执行异步撤消处理。反而代之的是�?/p>

设计成不依赖使用异步撤消那样的处�?

或�?br>

不得不��用线�E�撤消的话、不做异步撤消而作延迟撤消的处�?

�q�是比较实际的做法，是我们值得推荐的�?/p>

*1�Q�pthread_setcanceltype函数

*2�Q�pthread_setcancelstate函数

*3�Q�Solaris和HP-UX�{?/p>

lymons 2008-12-19 11:01 发表评论

lymons — Sun, 01 Jun 2008 13:41:00 GMT
摘要: Linux中处理来自共享对象的同步事�g 怎么利用设计模式来更有效的��用共享内�? �U�别�Q�中�{? Sachin Agrawal (sachin_agrawal@in.ibm.com), Senior Software Engineer, IBM Software Labs, IndiaSwati P. Udas (swatudas@in.ibm.com), Softw... 阅读全文

lymons 2008-06-01 21:41 发表评论

准则1�Q�不依赖于信��h��发的设计

lymons — Sun, 01 Jun 2008 12:27:00 GMT

From 2008�_�N�?/a>

�?/u>[C++] UNIX上的C++�E�序设计守则(1)

原文:http://d.hatena.ne.jp/yupo5656/20040712/p1

Unix跟Windows�{�那�?#8221;对于开发者易于��?#8221;的OS比�v来，在信号和�U�程的利用方面有诸多的限制。但是即使不知道�q�些知识��做构架设计和实现的情况也随处可见。这个就是那些经�怸�能再现的bug的温床吧�?/p>

因此�Q�我惛_��成几回来写一些准则来防止陷入到这些圈套里�?strong>

准则1�Q�不依赖于信��h��发的设计

·�l�其他进�E�以及自己发送异步信号�ƈ改变处理��程的设计不要做

异步信号是值用kill�pȝ��调用来创�?发送的信号、例如SIGUSR1,SIGUSR2,SIGINT,SIGTERM �{?
��单的使用忽略信号(SIG_IGN)则没有问�?

·不要把线�E�和信号一起��?nbsp;

�q�将使程序动作的预测和调试变得很困难

说明�Q?/p>

同步信号是指�Q�因为某些特定的操作*1而引起向自��n�q�程发送某些特定的信号�Q�例如SIGSEGV,SIGBUS,SIGPIPE,SIGSYS,SIGILL,SIGFPE。异步信号就是这些以外的信号。在什么时机发送异步信号�ƈ不能被预��出来。我们会在程序里�q�加收到某些信号时做一些特�D�处�?信号处理函数)的函数。那么根据收到的信号��p��C��号处理函数的�E�序��叫�?#8221;在�Q意代码处都能发生跌��{”的程序。这��L��E�序往往隐藏�q�下面的那些问题�Q?/p>

�Ҏ��引入BUG�?#8221;��L��的代�?#8221;虽然也包�?#8221;执行C/C++里面的一条语句的�q�程�?#8221;的意思，但这很容易蟩出程序员的正常思维以及默认的假定条件。编写程序的时候往往需要考虑比C++异常分支�q�要多得多的分支情况�?
使测试项目激�?/strong>。即使根据白盒测试达�?00%的分支覆�?也不能网�|�到因�ؓ接受信号而发生的跌��{分支处理。也��是说做�?00%的网�|�信可��转分支的��试是不能全部实现的。一般的�Q�加上要考虑” 在实行某个特定代码时因�ؓ接受��C��可��发生的误操�?#8221;�q�样的BUG会经常发�?a title="id:yupo5656:20040703 のsigsafeの記事を参照" >*2的这�U�情况，��试困难往往��是��D��软�g的品质低下的诱因�?

�Ҏ��l�验�Q?#8221;当检查到子进�E�结�?接收到SIGCHLD信号)�Ӟ��要做必要的处�?#8221;像这��L��信号处理不管做什么都是有必要的情况会有，但是除此以外的信号处理，例如

把自��q��状态用信号告诉其他�q�程
�ȝ��E�在输入输出函数里发送信��L��被阻塞的子线�E�，�q�解除阻�?

�{�，是应该事先好好好好考虑�q�后再去做实际的实现。前者的话，如果不强制在”普通的”�q�程间进行通信的话可能会很好，后者是�Ҏ��要��用线�E�，也要应该按照即��d��了也不能发生问题那样再设计�?/p>
不管怎么��P��如果必须要��用信��L��话，也要先全�?a title="とりあえず「鉄則２」を :-) " >*3理解�q�些陷阱以及�Q�和多线�E��Y件设计的场合一��h��者说比它更严格的制约.注意事项都需要铭记在心里�?/p>
*1�Q�例如，引用�I�指�?/p>
*2�Q�参�?id:yupo5656:20040703 的sigsafe说明

*3�Q�暂时先掌握”准则2”:-)

lymons 2008-06-01 20:27 发表评论

准则2�Q�要知道信号处理函数中可以做那些处理

lymons — Sun, 01 Jun 2008 12:22:00 GMT

From 2008�_�N�?/a>

UNIX�?/span>C++�E�序设计守则 (2)
原文地址�Q?/span>http://d.hatena.ne.jp/yupo5656/20040712/p2

准则2: 要知道信号处理函��C��可以做那些处�?/span>
· 在用sigaction函数登记的信号处理函��C��可以做的处理是被严格限定�?/span>
· 仅仅允许做下面的三种处理
   1. 局部变量的相关处理
   2. “volatile sig_atomic_t”�c�d��的全局变量的相��x��?/span>
   3. 调用异步信号安全的相兛_��?/span>
· 以外的其他处理不要做�Q?/span>

说明�Q?/span>
因�ؓ在收��C��h��要做一些处理，那通常是准备一个信号处理函数�ƈ�?/span>sigaction函数把它和信号名�q�行兌��的话��?/span>OK了。但是，在这个信号处理函数里可以做的处理是像上面那样被严格限定的。没有很好掌握这些知识就随便写一些代码的话就会引起下面那��L��问题�Q?/span>
· 问题1: 有程序死锁的危险
   o �q�是那些依赖于某一时刻�Q�而且错误再现比较困难�?/span>BUG产生的真正原�?/span>
   o 死锁是一个比较典型的例子�Q�除此之外还能引起函数返回��g��正确�Q�以及在某一函数内执行时�H�然收到SEGV信号�{�的误操作�?/span>
   �?/em>译者注1�Q?/span>SEGV通常�?/span>生在�q?/span>�E?/span>试图讉K��无效内存区域�?/span>�Q�可能是�?/span>NULL�?/span>�?/span>�Q�或��出�q?/span>�E�空�?/span>之外的内存地址�Q�。当bug原因�?/span>SEGV影响在不�?/span>旉��?/span>现时�Q�它�?/span>�?/span>别难于捕�?/span>到�?/span>

· 问题2: �׃��~�译器无意识的优化操作，有导致程序紊��q��危险
   o �q�是跟编译器以及�~�译器优化��别有关系�?/span>bug。它也是“�~�译器做了优化处理而不能正常动�?#8221;�Q?#8220;因�ؓinline化了�E�序不能动作�?#8221;�Q?#8220;变换�?/span>OS了程序也不能动作”�{�这些解析困�?/span>bug产生的原因�?/span>

�q�是一边看具体的代码一边解说吧。在下面的代码里臛_��有三个问题，�Ҏ��环境的不同很可能引�v不正��的动作 ^*1�?/span>按照�ơ序来说明里面的错误�?/span>

1int gSignaled;
2void sig_handler(int signo) {
3    std::printf("signal %d received!\n", signo);
4    gSignaled = 1;
5}
6int main(void) {
7    struct sigaction sa;
8　　// (省略)
9　　sigaction(SIGINT, &sa, 0);
10    gSignaled = 0;
11    while(!gSignaled) {
12　　//std::printf("waiting\n");
13        struct timespec t = { 1, 0 }; nanosleep(&t, 0);
14    }
15}
16

错误1: 竞争条�g
    在上面的代码里有竞争条�g�?/span>�?/span>sigaction函数被调用后�?/span>�?/span>gSignaled�q�未被赋值成0��g��前，如果接受�?/span>SIGINT信号了那会变得怎么样呢? 在信号处理函��C��被覆写成1后的gSignaled会在信号处理函数�q�回后被初始化成0�?/span>在后面的while循环里可能会变成��d�@�?/span>�?/span>

错误2: 全局变量gSignaled 声明的类型不正确
     在信号处理函数里使用的全局变数gSignaled的类型没有声明成volatile sig_atomic_t �?/span>�q�样的话�?/span>在执�?/span>while循环里的代码的时候接收到了了SIGINT信号�?/span>�?/span>有可能引�?/span>while的死循环�?/span>那�ؓ什么能引�v�q�样的情况呢�Q?span>
    · 信号处理函数里，把内存上gSignaled的值变更成1 �Q�它的汇�~�代码如下：

          movl    $1, gSignaled
    · 但是�Q�就像下面的代码描述的那��P��main函数是把gSignaled的值存攑ֈ�了寄存器�?/span>�?/span>�?/span>while循环之前�Q�仅仅是做了一�ơ拷贝变�?/span>gSignaled内存上的值到寄存器里�?/span>而在while循环里只是参照这个寄存器里的�?/span>�?/span>

          movl     gSignaled, %ebx
       .L8:
                       testl    %ebx, %ebx
                       jne      .L8

     在不执行优化的情况下�~�译后编译器有可能不会生成上面那��L��伪代�?/span>�?/span>�?/span>Gcc当��?/span>-O2选项做优化编译时�Q�生成的实际那样的汇�~�代码��生的危害�q�不仅仅是像上面说的威胁那样��单。这斚w��的问题，是设备驱动的开发者所要知道的常识�Q�但现实情况是对于应用程序的设计�?/span>.开发者几乎都不知道这些知识�?/span>
��Z��解决上面的问题，全局变量gSignaled的类型要像下面那样声�?/span>�?/span>

     volatile sig_atomic_t gSignaled;

     volatile则是提示�~�译器不要像上面那样做优化处理，变成每次循环都要参照该变量内存里的值那栯��行编译。所以在信号处理函数里把该变量的��g��改后也能真实反映�?/span>main函数�?/span>while循环�?/span>�?/span>
sig_atomic_t 是根�?/span>CPU�c�d��使用typedef来适当定义的整数��|��例如x86�q�_��?/span>int�c?/span>�?/span>�?/span>��是�?/span>”用一条机器指令来更新内存里的最�?a target=_blank name=20040712fn2>数据�?/span>(参照译者注2)�?/span>另外�Q?/span> sig_atomic_t�c�d��的变量的取��D��围是�?/span>SIG_ATOMIC_MIN/MAX之间 (参见§7.18.3/2)�?/span>有无�W�号是跟具体的实现有兟뀂考虑到移植性取值在0�?span>127之间是比较合适的�?span>C99也支持这个取��D��?/span>�?/span>C++规范(14882:2003)里也有同��L��描述�?/span>��切的位�|�是§1.9/9�q�里�?/span>�?/span>SUSv3的相��x��q�请参�?/span>sigaction�q�里^*3�?/span>此外�?/span>虽然�?/span>GCC的参考手册里�?/span>说了把指针类型更新成原子操作�Q�但在标�?/span>C/C++却没有记�?/span>^*5�?/span>你一定会惊讶于这个表里的函数��吧�?/span>
另外�Q�一定不要忘��C��下的几点�Q?/span>
    · 虽然�?/span>SUSv3里有异步信号安全(async-signal-safe)函数的一览，但根据不同的操作�pȝ��Q�某些函数是没有被实现的。所以一定要参考操作系�l�的手册
    · �W�三者做成的函数�Q�如果没有特别说明的场合�Q�首先要假定�q�个函数是不可重入函敎ͼ�不能随便在信号处理函��C��使用�?/span>
    · 调用不可重入函数的那些函数就会变成不可重入函��C��

    最后，��Z��明确赯��Q�想说明一下什么是” 异步信号安全(async-signal-safe)”函数�?/span>异步信号安全函数是指”在该函数内部即��因�ؓ信号而正在被中断�Q�在其他的地方该函数再被调用了也没有��M��问题”。如果函��C��存在更新静态区域里的数据的情况(例如�Q?/span>malloc)�Q�一般情况下都是不全的异步信号函数。但是，即��使用静态数据，如果在这里这个数据时候把信号屏蔽了的话，它就会变成异步信号安全函��C��?/span>
�?/span>译者注3�Q�不可重入函数就不是异步信号安全函数

*1�Q?span>sigaction函数被调用前�Q�一接收�?/span>SIGINT信号��q��止程序，暂且除外�?/span>
*2�Q?/span>“最�?#8221;是不完全正确�?/span>�?/span>例如�Q?/span>Alpha�q�_��?/span>32/64bit的变量用一条命令也能被更新�Q�但是好像把8/16bit的数据更新编�E�了多条命��o�?/span>�?/span>http://lists.sourceforge.jp/mailman/archives/anthy-dev/2005-September/002336.html 请参考这�?/span>URL地址�?/span>
*3�Q?/font>If the signal occurs other than as the result of calling abort(), kill(), or raise(), the behavior is undefined if the signal handler calls any function in the standard library other than one of the functions listed in the table above or refers to any object with static storage duration other than by assigning a value to a static storage duration variable of type volatile sig_atomic_t. Furthermore, if such a call fails, the value of errno is unspecified.
*4�Q?/span>在这个手册里“ In practice, you can assume that int and other integer types no longer than int are atomic. ”�q�部分是不正��的�?/span>请参�?/span>Alpha的例�?/span>
*5�Q?span>The following table defines a set of functions that shall be either reentrant or non-interruptible by signals and shall be async-signal-safe. 后面有异步信号安全函��C��?/span>

lymons 2008-06-01 20:22 发表评论

准则3�Q�多�U�程�E�序里不准��用fork

lymons — Sun, 01 Jun 2008 12:16:00 GMT
     摘要: From 2008�_�N�? 鉄則3: マルチスレッドのプログラムでのforkはやめよう准�?�Q�多�U�程�E�序里不准��用fork マルチスレッドのプログラムで、「自わV��ッド以外のスレッドが存在している状態」でfork 何が赗��るか能引起什么问题呢? 実例から見て�ѝ��しょう。次のコヹ{��を実行すると、子プロゅR��は実�?..  阅读全文

lymons 2008-06-01 20:16 发表评论

在xml里追加结�Ҏ��d��回�R(libxml2)

lymons — Fri, 30 Nov 2007 05:44:00 GMT
     摘要: 隐锋同学的blog上有关于libxml2的一��文章，正好最�q�要使用�q�个库来处理xml文�g�?
不过在测试时我们发现用文章里F. ��d��属性例�E�代�?�Ӟ��d��的keyword�l�点后面没有回�R�Q?
跟后面的�l�点挤在一行了�Q�不是很好看�?
例如�Q�以下的xml例子文�g  阅读全文

lymons 2007-11-30 13:44 发表评论

�l�文仉��讑֮�timeout

lymons — Mon, 26 Nov 2007 06:52:00 GMT

From 2008�_�N�?/a>

Linux 文�g锁是��锁，也有人把它叫做记录锁�Q�是通过�pȝ��调用fcntl(2)来实现的�?br>�q�种锁在锁定文�g时有两种模式�Q�分别是��d��(block)和非��d��模式�?br>在编码时比较常用的是有一�U�的非阻塞模式，也就是发现文件已�l�被其他�q�程
锁定�Ӟ��立即�q�回不予�{�待。而阻塞模式则正好与它相反�Q�也��是一直等待直�?br>其他�q�程释放文�g锁�ؓ止�?br>注：关于详细内容请参看《Unix环境高��~�程�?/span>

不过�Q�有的时候也会用到阻塞模式的文�g锁，而且会要求不能被一直阻塞，�{�待
了一定时间后应返回。也��是��_��想��d��版本的文仉��加上一个超时时�?timeout)�?br>
通过man手册�Q�fcntl(2)里面没有关于在阻塞模式时�Q�设�|�超时时间的��M��描述�?br>但从man手册里我们发玎ͼ�文�g锁在��d��时会被信�?signal)中断。所以我们就�?br>可以利用讄��信号软中断来实现一个自��q��本的�{�待��时呢�?br>

1 #include <stdio.h>
2 #include <stdlib.h>
3 #include <unistd.h>
4 #include <fcntl.h>
5 #include <sys/types.h>
6 #include <sys/stat.h>
7 #include <signal.h>
8
9 #define readw_lock(fd) \
10     lock_reg((fd), F_SETLKW, F_RDLCK)
11 #define writew_lock(fd) \
12     lock_reg((fd), F_SETLKW, F_WRLCK)
13 #define unlock(fd) \
14     lock_reg((fd), F_SETLK, F_UNLCK)
15
16 typedef int (*LW_FN)(char *fname);
17
18 int
19 lock_reg(int fd, int cmd, int type)
20 {
21     struct flock lock;
22     lock.l_type = type;
23     lock.l_start = 0;
24     lock.l_whence = SEEK_SET;
25     lock.l_len = 0;
26
27     return fcntl(fd, cmd, &lock);
28 }
29
30 void hander(int signo)
31 {
32     // do nothing
33     return;
34 }
35
36 int lockw(char *fname, LW_FN fn, int timeout)
37 {
38     int ret = 0;
39     int fd;
40     struct sigaction act, oact;
41
42     if ((fd = open(fname,  O_CREAT | O_RDWR, 0666)) == -1) {
43         printf("open failed!\n");
44         return -1;
45     }
46
47     // set timer to wakeup fcntl
48     act.sa_handler = hander;
49     sigemptyset(&act.sa_mask);
50     act.sa_flags = 0; // here, must be zero for wakeup fcntl
51     sigaction(SIGALRM, &act, &oact);
52
53     int sec = alarm(timeout);
54
55     if (writew_lock(fd) == 0) {
56         alarm(sec);
57         // recovery signal handler.
58         sigaction(SIGALRM, &oact, NULL);
59
60         printf("locked OK!\n");
61
62         // here, add code about file.
63 #ifdef _TEST
64         getchar();
65         ret = 0;
66 #else
67         ret = fn(fname);
68 #endif
69
70         printf("unlocked!\n");
71         unlock(fd);
72     }
73     else {
74         alarm(sec);
75         // recovery signal handler.
76         sigaction(SIGALRM, &oact, NULL);
77         // lock failed, because of timeout.
78         printf("write lock failed\n");
79         ret = -1;
80     }
81
82     return ret;
83 }
84
85 // test code
86 int func(char *fname)
87 {
88     printf("check file:%s \n", fname);
89     getchar();
90     return 0;
91 }
92
93 int main()
94 {
95     return lockw("file.lock", func, 5);
96 }
97
98

该程序的原理是，利用了alarm(2)讄��的定时器�Q�在一定时间过后会产生SIGALRM信号�Q�会使当前正�?br>执行的系�l�调用中断，��D��该系�l�调�?fcntl)�q�回��p�|�?/span>

上述代码有以下的说明�Q?br> 1. 信号处理函数hander是一个空函数�Q�里面什么也不做。它的存在就是�ؓ了接�?strong>SIGALRM信号
2. sigaction�?strong>sa_flags成员一定要讄��?�Q�否则不会是�pȝ��调用中断
3. ��Z��防止把以前设�|�的定时器破坏，不管是加锁成功还是失败都立即恢复以前的定时器�?br> 4. 因�ؓ��Z��接收SIGALRM信号�Q�我们设�|�了它的信号处理函数。那在加锁失败和成功后也要恢复以前的讑֮��?br>
注：虽然上面的代码能实现文�g锁超时等待的问题�Q�但又引入了另一个问题，��是该代码会破坏以前讑֮�的定时器�Q�即使是后面也恢复了以前的定时器讄��Q�也会有一些副作用。比如：当�ؓ了等待其他进�E�释放文仉��Q�传递到lockw函数里的�{�待旉��(也就是�Ş参timeout)��过了以前设定的定时器触发时��_��那这�D�|��间内的以前设定的定时器就无效了。也��是�? 在调用lockw之前,该进�E�了已经讑֮�了一�?�U�的定时�? 而这个进�E�在调用lockw时传递的timeout旉��?0�U?锁定的阻塞时间�ؓ10�U?, 那么从调用lockw的那一刻�v,2�U�的定时器就无效�?知道锁定成功或者失败�ؓ�?

lymons 2007-11-26 14:52 发表评论

亚洲视频在线播放,美女国产一区,欧美三级小说

C++ 局部静态初始化不是�U�程安全的！

��h���?C++ 局部静态初始化不是�U�程安全!

在C++下编写synchronized method比较�?(1)

�?/span>[C++] 在C++下编写synchronized method比较�?2)

�?/span>[C++] 用C++�~�写synchronized method比较�?(3)

设计模式在Linux文�g�pȝ��中的���单实�?

用lex/yacc来解析配�|�文�?

RX-RPC的客��L��与服务器端的通信解析

Linux中处理来自共享对象的同步事�g

准则6�Q�遵守多�U�程�~�程的常识（下）

UNIX上C++�E�序设计守则(6)

准则6�Q�遵守多�U�程�~�程的常识（上）

UNIX上C++�E�序设计守则(6)

准则5�Q�尽可能避免�U�程的�g�q�撤销处理

[C++] UNIX上C++�E�序设计守则(5)

原文地址�Q�http://d.hatena.ne.jp/yupo5656/20040724/p1

�?/span>[C++] UNIX上的C++�E�序设计守则 (4)

会造成什么问题呢

准则1�Q�不依赖于信��h��发的设计

准则2�Q�要知道信号处理函数中可以做那些处理

准则3�Q�多�U�程�E�序里不准��用fork

在xml里追加结�Ҏ����d��回�R(libxml2)

�l�文仉���讑֮�timeout

��h��?C++ 局部静态初始化不是�U�程安全!

设计模式在Linux文�g�pȝ��中的��单实�?

在xml里追加结�Ҏ��d��回�R(libxml2)

�l�文仉��讑֮�timeout