线程内调用类对象报错

Question

DWORD WINAPI ReadItemDataProc(LPVOID lpParameter)
{
HRESULT r1;
BSTR bstrItem;
CLeftTopView *ltv = new CLeftTopView();
COPCClientDoc *pDoc = (COPCClientDoc*)lpParameter;
// int nCount = ltv.arrayItem.GetSize();
CString str = ((CItem*)ltv->arrayItem.GetAt(i))->strDataSource;
执行到最后一句报错Debug Assertion Failed!
其中ReadItemDataProc为一个外部的线程函数，CLeftTopView 为视图类，CItem为自定义类，传进来的参数lpParameter为文档类指针,arrayItem为CPtrArray类型的变量,编译没错，请问最后一句错在哪里？

Answer 1

断言错误的原因有很多可能，检测一下 arrayItem.GetAt(i) 指针是否为空指针。

Answer 2

Description of CWnd derived MFC objects and multithreaded applications in Visual C++
SUMMARY
In a multi-threaded application written using MFC, you should not pass MFC objects across thread boundaries. As a general rule, a thread should access only those MFC objects that it creates. Failure to do so may cause run-time problems including assertions or unexpected program behavior. 
Back to the topMORE INFORMATION
In a Win32 process, all the threads running in the process address space can view all global and static data. A thread can use thread-local-storage (TLS) to store any thread-specific data. In a multi-threaded environment because windows are owned by threads, MFC keeps the temporary and permanent window handle map in thread local storage. The same is true for other handle maps like those for GDI objects and device contexts. Keeping the window handle maps in thread local storage ensures protection against simultaneous access by several threads. The behavior of the functions CHandleMap::LookupPermanent() and CHandleMap::LookupTemporary() is a direct consequence of these facts. Given a window handle, these functions check the permanent and temporary window handle maps of the current thread for the existence of an associated CWnd derived MFC object. This means that if calls to these functions are made from a thread to search for MFC objects that represent windows created in other threads, these calls will fail. There are several functions that call CHandleMap::LookupPermanent() and CHandleMap::LookupTemporary(). CWnd::AssertValid() (and hence the macro ASSERT_VALID for a CWnd object) is one such function. This function is called to make validity checks on an object. If AssertValid() fails to find an entry for the MFC object's m_hWnd member in any of the handle maps or finds an incorrect entry, it fires an assertion. In Visual C++ 2.1, these assertions are in file Wincore.cpp, lines 797 and 798. In Visual C++ 2.2, they are in Wincore.cpp, lines 804 and 805. In Visual C++ 4.0, they are in Wincore.cpp, lines 871 and 872. Calls to the ASSERT_VALID macro are sprinkled all over the MFC source code. Hence, from a particular thread, if you end up calling a function that calls ASSERT_VALID on MFC window objects that belong to some other thread, you get an assertion. If you do not get an assertion, you may still get abnormal behavior because you are not allowed to directly manipulate windows created by other threads. The correct approach in such situations is to work with window handles, not MFC objects. It is safe to pass window handles across thread boundaries. If thread A passes a window handle to thread B, then thread B can use this window handle to send or post messages to the window. When these messages are processed, you are back in the context of thread A and calls to CWnd::AssertValid() to check thread A's window handle maps will succeed. In this scenario, thread B can also use the CWnd::FromHandle() function to get a temporary CWnd object which is placed in thread B's temporary handle map. However this object may be of only limited use, because in no way is it in synchronization with the MFC object existing in thread A's handle maps

Answer 3

你在线程中重新new一个视图对象是错误的。这个视图对象，并不是你框架中当前运行的视图对象，虽然它们是从同一个视图类产生的。虽然你新建的视图对象中也有arrayItem这个数组，但你GetAt(i)是导致崩溃的根源，因为新建的视图对象中的数组里应该什么也没有。而你实际需要的内容是在当前运行的视图对象中。尝试一下通过pDoc指针去获取当前正在运行的CLeftTopView 视图对象。

Answer 4

本身跨线程传递MFC对象指针就不妥，楼主的代码...，CLeftTopView跟CItem有什么关系，是父子关系哪？这样强制转换访问其成员变量？

Answer 5

补充一下，CLeftTopView是切割的视图类