DWORD ret; const int THREAD_NUM = 100; HANDLE handle[THREAD_NUM]; for (int i = 0; i < THREAD_NUM; i++) handle[i] = (HANDLE)_beginthreadex(NULL, 0, CthreadFun, NULL, 0, NULL); ret = WaitForMultipleObjects(THREAD_NUM, handle, TRUE, INFINITE);
如上写了个使用_beginthreadex的例子,发现当THREAD_NUM为100时,WaitForMultipleObjects返回的是0xffffffff。
除了什么错误呢,于是使用GetLastError()获取错误号:87,使用vs工具中的错误查找,查找对应的错误信息是"参数错误"。这是什么原因呢?
如果把THREAD_NUM改小后,就没有这个错误了,为什么呢?
假设:
1)WaitForMultipleObjects对参数ncount有大小要求?
2)系统可开的线程个数有限制?
3)线程太多,占用的内存资源多?
使用排除法进行分析:
关于3),_beginthreadex的第二个参数表示堆栈大小,以字节为单位,0默认1M。 100个线程才100M,况且查看内存使用量,没有太多呀!
关于2),msdn原文:
“The number of threads a process can create is limited by the available virtual memory. By default, every thread has one megabyte of stack space. Therefore, you can create at most 2,028 threads. If you reduce the default stack size, you can create more threads. However, your application will have better performance if you create one thread per processor and build queues of requests for which the application maintains the context information. A thread would process all requests in a queue before processing requests in the next queue.”
参考文章:http://www.cnblogs.com/lancidie/archive/2011/12/15/2289337.html 理论上2048个线程数限制。可以通过改小栈的大小增加,默认虽然实际可能达不到2048,但是100个应该可以吧?
并且,如果是2,3的问题,那么在_beginthreadex时应该失败的呀,检查句柄数组handle, 均分配成功,因此排除2,3。
最后关于1)WaitForMultipleObjects的参数范围,参考msdn原文:
DWORD WINAPI WaitForMultipleObjects( _In_ DWORD nCount, _In_ const HANDLE *lpHandles, _In_ BOOL bWaitAll, _In_ DWORD dwMilliseconds );
Parameters
- nCount [in]
The number of object handles in the array pointed to by lpHandles. The maximum number of object handles is MAXIMUM_WAIT_OBJECTS. This parameter cannot be zero.
- lpHandles [in]
An array of object handles. For a list of the object types whose handles can be specified, see the following Remarks section. The array can contain handles to objects of different types. It may not contain multiple copies of the same handle.
If one of these handles is closed while the wait is still pending, the function's behavior is undefined.
The handles must have the SYNCHRONIZE access right. For more information, see Standard Access Rights.
- bWaitAll [in]
If this parameter is TRUE, the function returns when the state of all objects in the lpHandles array is signaled. If FALSE, the function returns when the state of any one of the objects is set to signaled. In the latter case, the return value indicates the object whose state caused the function to return.
- dwMilliseconds [in]
The time-out interval, in milliseconds. If a nonzero value is specified, the function waits until the specified objects are signaled or the interval elapses. If dwMilliseconds is zero, the function does not enter a wait state if the specified objects are not signaled; it always returns immediately. If dwMilliseconds is INFINITE, the function will return only when the specified objects are signaled.
Return value
If the function succeeds, the return value indicates the event that caused the function to return. It can be one of the following values. (Note that WAIT_OBJECT_0 is defined as 0 and WAIT_ABANDONED_0 is defined as 0x00000080L.)
Return code/value Description
- WAIT_OBJECT_0 to ( WAIT_OBJECT_0 + nCount– 1)
If bWaitAll is TRUE, the return value indicates that the state of all specified objects is signaled.
If bWaitAll is FALSE, the return value minus WAIT_OBJECT_0 indicates the lpHandles array index of the object that satisfied the wait. If more than one object became signaled during the call, this is the array index of the signaled object with the smallest index value of all the signaled objects.
- WAIT_ABANDONED_0 to ( WAIT_ABANDONED_0 + nCount– 1)
If bWaitAll is TRUE, the return value indicates that the state of all specified objects is signaled and at least one of the objects is an abandoned mutex object.
If bWaitAll is FALSE, the return value minus WAIT_ABANDONED_0 indicates the lpHandles array index of an abandoned mutex object that satisfied the wait. Ownership of the mutex object is granted to the calling thread, and the mutex is set to nonsignaled.
If a mutex was protecting persistent state information, you should check it for consistency.
- WAIT_TIMEOUT
- 0x00000102L
The time-out interval elapsed and the conditions specified by the bWaitAll parameter are not satisfied.
- WAIT_FAILED
- ( DWORD)0xFFFFFFFF
The function has failed. To get extended error information, call GetLastError
其中MAXIMUM_WAIT_OBJECTS的值为64.这就可以解释了错误号87的问题了。其实解决问题时,绕了个弯,87就是参数错误的意思,当然要首先从出错的函数参数方面找原因,因为自己主观首先臆测了参数范围无限制,导致了浪费时间。
注意以后解决问题要严谨,不可自我感觉,必须有凭有据。