平台域8_不必要的一字节对齐引发程序吊死.doc

1 现象：问题描述
某程序从Windows移植到AIX环境下后，运行时，总是在进入pthread_mutex_lock函数后不返回。
2 关键过程：根本原因分析
此程序涉及到的数据结构如下：
Class A
{
char m_cValue;
CRITICAL_SECTION m_csLock;   // CRITICAL_SECTION是通过pthread_mutex_t实现
……….
}

像这样的定义无可厚非，但由于将程序从Windows移植到Unix时，将类A包含在一字节对齐的声明中，导致了问题。
虽然pthread_mutex_t中的结构不会受一定节对齐的影响（参见备注中的AIX下pthread_mutex_t结构定义），但pthread_mutex_lock函数却由于某些未知的原因导致阻塞。对于库函数底层的实现我们不得而知，在移植中发生多次类似的现象使我们总结出此经验。
3 结论：解决方案及效果
修改代码，将类A放到一字节对齐声明外面，问题得到解决。
4 经验总结：预防措施和规范建议
像锁这样的东西一般不会出现在消息中，不会涉及到需要一字节对齐这样的问题，不应包含在一字节对齐声明中。
如果将锁包含在一字节对齐声明中，没有经验的话，很难定位这样的问题：往往会误认为是死锁问题来定位。
5 备注
pthread_mutex_t在AIX下的定义如下：
typedef struct
{
#ifdef __64BIT__
        long    __mt_word[8];
#else
        int     __mt_word[13];
#endif /* __64BIT__ */
} pthread_mutex_t;
6 考核点
一字节对齐应用在锁变量上，可能会导致加锁函数不返回。
7 试题
以下结构不应该放在一字节对齐声明中的是（D）
A． 
Class A
{
char m_cValue;
int m_iValue;
}
B． 
Class A
{
char m_cValue;
unsigned long m_ulValue;
}
C． 
Class A
{
char m_cValue;
pthread_t m_ThradID;
unsigned long m_ulValue;
}
D． 
Class A
{
char m_cValue;
CRITICAL_SECTION m_csLock;   // CRITICAL_SECTION是通过pthread_mutex_t实现
unsigned long m_ulValue;
}