mfc界面包装类 ——多线程时成员函数调用的断言失败

经常在论坛上看到如下的问题：
dword winapi threadproc( void *pdata )  // 线程函数（比如用于从com口获取数据）
{
    // 数据获取循环
    // 数据获得后放在变量i中
    cabcdialog *pdialog = reinterpret_cast< cabcdialog* >( pdata );
    assert( pdialog );  // 此处如果assert_valid( pdialog )将断言失败
    pdialog->m_data = i;
    pdialog->updatedata( false );  // updatedata内部assert_valid( this )断言失败
    …
}
bool cabcdialog::oninitdialog()
{
    cdialog::oninitdialog();
    // 其他初始化代码
    createthread( null, 0, threadproc, this, 0, null );  // 创建线程
    return true;
}
    注意上面注释中的两处断言失败，本文从mfc底层的实现来解释为什么会断言失败，并说明mfc为什么要这样实现及相应的处理办法。
    在说明mfc界面包装类的底层实现之前，由于其和窗口有关，故先讲解窗口类这个基础知识以为后面做铺垫。

窗口类

    窗口类是一个结构，其一个实例代表着一个窗口类型，与c++中的类的概念非常相近（虽然其表现形式完全不同，c++的类只不过是内存布局和其上的操作这个概念的类型），故被称作为窗口类。
    窗口是具有设备操作能力的逻辑概念，即一种能操作设备（通常是显示器）的东西。由于窗口是窗口类的实例，就象c++中的一个类的实例，是可以具有成员函数的（虽然表现形式不同），但一定要明确窗口的目的——操作设备（这点也可以从microsoft针对窗口所制订的api的功能看出，主要出于对设备操作的方便）。因此不应因为其具有成员函数的功能而将窗口用于功能对象的创建，这虽然不错，但是严重违反了语义的需要（关于语义，可参考我的另一篇文章——《语义的需要》），是不提倡的，但却由于mfc界面包装类的加入导致大多数程序员经常将逻辑混入界面。
    窗口类是个结构，其中的大部分成员都没什么重要意义，只是microsoft一相情愿制订的，如果不想使用界面api（windows user interface api），可以不管那些成员。其中只有一个成员是重要的——lpfnwndproc，消息处理函数。
    外界（使用窗口的代码）只能通过消息操作窗口，这就如同c++中编写的具有良好的面向对象风格的类的实例只能通过其公共成员函数对其进行操作。因此消息处理函数就代表了一个窗口的一切（忽略窗口类中其他成员的作用）。很容易发现，窗口这个实例只具有成员函数（消息处理函数），不具有成员变量，即没有一块特定内存和一特定的窗口相关联，则窗口将不能具有状态（windows还是提供了window properties api来缓和这种状况）。这也正是上面问题发生的根源。
    为了处理窗口不能具有状态的问题（这其实正是windows灵活的表现），可以有很多种方法，而mfc出于能够很容易的对已有窗口类进行扩展，选择了使用一个映射将一个窗口句柄（窗口的唯一标示符）和一个内存块进行绑定，而这块内存块就是我们熟知的mfc界面包装类（从cwnd开始派生延续）的实例。

mfc状态

    状态就是实例通过某种手段使得信息可以跨时间段重现，c++的类的实例就是由外界通过公共成员函数改变实例的成员变量的值以实现具有状态的效果。在mfc中，具有三种状态：模块状态、进程状态、线程状态。分别为模块、进程和线程这三种实例的状态。由于代码是由线程运行，且和另外两个的关系也很密切，因此也被称作本地数据。
模块本地数据
    具有模块本地性的变量。模块指一个加载到进程虚拟内存空间中的pe文件，即exe文件本身和其加载的dll文件。而模块本地性即同样的指针，根据代码从不同的模块执行而访问不同的内存空间。这其实只用每个模块都声明一个全局变量，而前面的“代码”就在mfc库文件中，然后通过一个切换的过程（将欲使用的模块的那个全局变量的地址赋给前述的指针）即可实现模块本地性。mfc中，这个过程是通过调用afxsetmodulestate来切换的，而通常都使用afx_manage_state这个宏来处理，因此下面常见的语句就是用于模块状态的切换的：
afx_manage_state( afxgetstaticmodulestate() );
    mfc中定义了一个结构（afx_module_state），其实例具有模块本地性，记录了此模块的全局应用程序对象指针、资源句柄等模块级的全局变量。其中有一个成员变量是线程本地数据，类型为afx_module_thread_state，其就是本文问题的关键。
进程本地数据
    具有进程本地性的变量。与模块本地性相同，即同一个指针，在不同进程中指向不同的内存空间。这一点windows本身的虚拟内存空间这个机制已经实现了，不过在dll中定义的全局变量，如果dll支持win32s，则其是共享其全局变量的，即不同的进程加载了同一dll将访问同一内存。win32s是为了那些基于win32的应用程序能在windows 3.1上运行，由于windows 3.1是16位操作系统，早已被淘汰，而现行的dll模型其本身就已经实现了进程本地性（不过还是可以通过共享节来实现win32s中的dll的效果），因此进程状态其实就是一全局变量。
    mfc中作为本地数据的结构有很多，如_afx_win_state、_afx_debug_state、_afx_db_state等，都是mfc内部自己使用的具有进程本地性的全局变量。
线程本地数据
    具有线程本地性的变量。如上，即同一个指针，不同的线程将会访问不同的内存空间。这点mfc是通过线程本地存储（tls——thread local storage，其使用方法由于与本文无关，在此不表）实现的。
    mfc中定义了一个结构（_afx_thread_state）以记录某些线程级的全局变量，如最近一次的模块状态指针，最近一次的消息等。
模块线程状态
    mfc中定义的一个结构（afx_module_thread_state），其实例即具有线程本地性又具有模块本地性。也就是说不同的线程从同一模块中和同一线程从不同模块中访问mfc库函数都将导致操作不同的内存空间。其应用在afx_module_state中，记录一些线程相关但又模块级的数据，如本文的重点——窗口句柄映射。

包装类对象和句柄映射

    句柄映射——chandlemap，mfc提供的一个底层辅助类，程序员是不应该直接使用它的。其有两个重要的成员变量：cmapptrtoptr m_permanentmap, m_temporarymap;。分别记录永久句柄绑定和临时句柄绑定。前面说过，mfc使用一个映射将窗口句柄和其包装类的实例绑定在一起，m_permanentmap和m_temporarymap就是这个映射，分别映射永久包装类对象和临时包装类对象，而在前面提到过的afx_module_thread_state中就有一个成员变量：chandlemap* m_pmaphwnd;（之所以是chandlemap*是使用懒惰编程法，尽量节约资源）以专门完成hwnd的绑定映射，除此以外还有如m_pmaphdc、m_pmaphmenu等成员变量以分别实现hdc、hmenu的绑顶映射。而为什么这些映射要放在模块线程状态而不放在线程状态或模块状态是很明显的——这些包装类包装的句柄都是和线程相关的（如hwnd只有创建它的线程才能接收其消息）且这个模块中的包装类对象可能不同于另一个模块的（如包装类是某个dll中专门派生的一个类，如a.dll中定义的cabutton的实例和b.dll中定义的cbbutton的实例如果同时在一个线程中。此时线程卸载了a.dll，然后cabutton的实例得到消息并进行处理，将发生严重错误——类代码已经被卸载掉了）。
包装类存在的意义有二：包装对hwnd的操作以加速代码的编写和提供窗口子类化（不是超类化）的效果以派生窗口类。包装类对象针对线程分为两种：永久包装类对象（以后简称永久对象）和临时包装类对象（以后简称临时对象）。临时对象的意义仅仅只有包装对hwnd的操作以加速代码编写，不具有派生窗口类的功能。永久对象则具有前面说的包装类的两个意义。
    在创建窗口时（即cwnd::createex中），mfc通过钩子提前（wm_create和wm_nccreate之前）处理了通知，用afxwndproc子类化了创建的窗口并将对应的cwnd*加入当前线程的永久对象的映射中，而在afxwndproc中，总是由cwnd::fromhandlepermanent（获得对应hwnd的永久对象）得到当前线程中当前消息所属窗口句柄对应的永久对象，然后通过调用得到的cwnd*的windowproc成员函数来处理消息以实现派生窗口类的效果。这也就是说永久对象具有窗口子类化的意义，而不仅仅是封装hwnd的操作。
    要将一个hwnd和一个已有的包装类对象相关联，调用cwnd::attach将此包装类对象和hwnd映射成永久对象（但这种方法得到的永久对象不一定具有子类化功能，很可能仍和临时对象一样，仅仅起封装的目的）。如果想得到临时对象，则通过cwnd::fromhandle这个静态成员函数以获得。临时对象之所以叫临时，就是其是由mfc内部（chandlemap::fromhandle）生成，其内部（chandlemap::deletetemp）销毁（一般通过cwinthread::onidle中调用afxunlocktempmaps）。因此程序员是永远不应该试图销毁临时对象的（即使临时对象所属线程没有消息循环，不能调用cwinthread::onidle，在线程结束时，chandlemap的析构仍然会销毁临时对象）。

原因

    为什么要分两种包装类对象？很好玩吗？注意前面提过的窗口模型——只能通过消息机制和窗口交互。注意，也就是说窗口是线程安全的实例。窗口过程的编写中不用考虑会有多个线程同时访问窗口的状态。如果不使用两种包装类对象，在窗口创建的钩子中通过调用setprop将创建的窗口句柄和对应的cwnd*绑定，不一样也可以实现前面说的窗口句柄和内存块的绑定？
    cwnd的派生类ca，具有一个成员变量m_bgcolor以决定使用什么颜色填充底背景。线程1创建了ca的一个实例a，将其指针传进线程2，线程2设置a.m_bgcolor为红色。这已经很明显了，ca::m_bgcolor不是线程安全的，如果不止一个线程2，那么a.m_bgcolor将会出现线程访问冲突。这严重违背窗口是线程安全的这个要求。因为使用了非消息机制与窗口进行交互，所以失败。
    继续，如果给ca一个公共成员函数setbgcolor，并在其中使用原子操作以保护m_bgcolor，不就一切正常了？呵，在ca::onpaint中，会两次使用m_bgcolor进行绘图，如果在两次绘图之间另一线程调用ca::setbgcolor改变了ca::m_bgcolor，问题严重了。也就是说不光是ca::m_bgcolor的写操作需要保护，读操作亦需要保护，而这仅仅是一个成员变量。
    那么再继续，完全按照窗口本身的定义，只使用消息与它交互，也就是说自定义一个消息，如am_setbgcolor，然后在ca::setbgcolor中sendmessage这个消息，并在其响应函数中修改ca::m_bgcolor。完美了，这是即符合窗口概念又很好的设计，不过它要求每一个程序员编写每一个包装类时都必须注意到这点，并且最重要的是，c++类的概念在这个设计中根本没有发挥作用，严重地资源浪费。
    因此，mfc决定要发挥c++类的概念的优势，让包装类对象看起来就等同于窗口本身，因此使用了上面的两种包装类对象。让包装类对象随线程的不同而不同可以对包装类对象进行线程保护，也就是说一个线程不可以也不应该访问另一个线程中的包装类对象（因为包装类对象就相当于窗口，这是mfc的目标，并不是包装类本身不能被跨线程访问），“不可以”就是通过在包装类成员函数中的断言宏实现的（在cwnd::assertvalid中），而“不应该”前面已经解释地很清楚了。因此本文开头的断言失败的根本原因就是因为违反了“不可以”和“不应该”。
    虽然包装类对象不能跨线程访问，但是窗口句柄却可以跨线程访问。因为包装类对象不仅等同于窗口，还改变了窗口的交互方式（这也正是c++类的概念的应用），使得不用非得使用消息机制才能和窗口交互。注意前面提到的，如果跨线程访问包装类对象，而又使用c++类的概念操作它，则其必须进行线程保护，而“不能跨线程访问”就消除了这个问题。因此临时对象的产生就只是如前面所说，方便代码的编写而已，不提供子类化的效果，因为窗口句柄可以跨线程访问。

解决办法

    已经了解失败的原因，因此做如下修改：
dword winapi threadproc( void *pdata )  // 线程函数（比如用于从com口获取数据）
{
    // 数据获取循环
    // 数据获得后放在变量i中
    cabcdialog *pdialog = static_cast< cabcdialog* >(
                              cwnd::fromhandle( reinterpret_cast< hwnd >( pdata ) ) );
    assert_valid( pdialog );  // 此处可能断言失败
    pdialog->m_data = i;      // 这是不好的设计，详情可参看我的另一篇文章：《语义的需要》
    pdialog->updatedata( false );  // updatedata内部assert_valid( this )可能断言失败
    …
}
bool cabcdialog::oninitdialog()
{
    cdialog::oninitdialog();
    // 其他初始化代码
    createthread( null, 0, threadproc, m_hwnd, 0, null );  // 创建线程
    return true;
}
    之所以是“可能”，因为这里有个重点就是临时对象是hwnd操作的封装，不是窗口类的封装。因此所有的hwnd临时对象都是cwnd的实例，即使上面强行转换为cabcdialog*也依旧是cwnd*，所以在assert_valid里调用cabcdialog::assertvalid时，其定义了一些附加检查，则可能发现这是一个cwnd的实例而非一个cabcdialog实例，导致断言失败。因此应将cabcdialog全部换成cwnd，这下虽然不断言失败了，但依旧错误（先不提pdialog->m_data怎么办），因为临时对象是hwnd操作的封装，而不幸的是updatedata只是mfc自己提供的一个对话框数据交换的机制（ddx）的操作，其不是通过向hwnd发送消息来实现的，而是通过虚函数机制。因此在updatedata中调用实例的dodataexchange将不能调用cabcdialog::dodataexchange，而是调用cwnd::dodataexchange，因此将不发生任何事。
    因此合理（并不一定最好）的解决方法是向cabcdialog的实例发送一个消息，而通过一个中间变量（如一全局变量）来传递数据，而不是使用cabcdialog::m_data。当然，如果数据少，比如本例，就应该将数据作为消息参数进行传递，减少代码的复杂性；数据多则应该通过全局变量传递，减少了缓冲的管理费用。修改后如下：
#define am_datanotify ( wm_user + 1 )
static dword g_data = 0;
dword winapi threadproc( void *pdata )  // 线程函数（比如用于从com口获取数据）
{
    // 数据获取循环
    // 数据获得后放在变量i中
    g_data = i;
    cwnd *pwnd = cwnd::fromhandle( reinterpret_cast< hwnd >( pdata ) );
    assert_valid( pwnd );  // 本例应该直接调用平台sendmessage而不调用包装类的，这里只是演示
    pwnd->sendmessage( am_datanotify, 0, 0 );
    …
}
begin_message_map( cabcdialog, cdialog )
    …
    on_message( am_datanotify, ondatanotify )
    …
end_message_map()
bool cabcdialog::oninitdialog()

{
    cdialog::oninitdialog();
    // 其他初始化代码
    createthread( null, 0, threadproc, m_hwnd, 0, null );  // 创建线程
    return true;
}
lresult cabcdialog::ondatanotify( wparam /* wparam */, lparam /* lparam */ )
{
    updatedata( false );
    return 0;
}
void cabcdialog::dodataexchange( cdataexchange *pdx )
{
    cdialog::dodataexchange( pdx );
    ddx_text( pdx, idc_edit1, g_data );