Is Maximum_Wait_Objects Really 64

Is MAXIMUM_WAIT_OBJECTS really 64?

Yes, that's really the value of that macro.

Whether that's really the maximum number of objects that the function is capable of waiting on at once is an internal implementation detail. But if I were writing that function, I'd check the given array length to make sure it was within the documented bounds before proceeding, even if the rest of the code happened to be capable of waiting for more, because I wouldn't want consumers of the API to use more than the documented maximum and then come to rely on such undocumented behavior, thus placing requirements on any potential implementations of the function in future releases of the OS

How to overcome the MAXIMUM_WAIT_OBJECTS restriction of WaitForMultipleObjects?

But it seems to me that both are too much effort.

If you want it to work with wait handles, that's what you'll have to do. But if all you need is something that will block until all of the threads have finished, you can use a Semaphore or perhaps a Synchronization Barrier.

How to implement waitAny on more than 64 handles?

You might want to consider implementing something like a queue for notification packets for the 'waitAny' thread to wait on. When one of your multitude of threads completes it's operation, it places a notification packet on the queue. Your waitAny turns into a wait on a single event that indicates something is in the queue.

Why does WaitForMultipleObjects fail with multiple thread handles?

The WaitForMultipleObjects() documentation states:

The maximum number of object handles is MAXIMUM_WAIT_OBJECTS.

The value of MAXIMUM_WAIT_OBJECTS is 64 (defined in winnt.h), so 100 handles is over the limit. However, the documentation also explains how to overcome that limit:

To wait on more than MAXIMUM_WAIT_OBJECTS handles, use one of the following methods:

• Create a thread to wait on MAXIMUM_WAIT_OBJECTS handles, then wait on that thread plus the other handles. Use this technique to break the handles into groups of MAXIMUM_WAIT_OBJECTS.

• Call RegisterWaitForSingleObject to wait on each handle. A wait thread from the thread pool waits on MAXIMUM_WAIT_OBJECTS registered objects and assigns a worker thread after the object is signaled or the time-out interval expires.

See the answer to this question for an example of the first technique.

EnterCriticalSection crashes with more than 64 threads

As nobody wants to answer my question, I will do it myself based on HansPassant's comment to my question.

He pointed out that the problem is WaitForMultipleObjects(), which takes a parameter

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.

(from msdn)

MAXIMUM_WAIT_OBJECTS is defined as 64, more informations in this thread.

This means: yes, there is a hard-coded limit on the amount of threads, but the restriction is not on EnterCriticalSection but on WaitForMultipleObjects, which returns an error code I should have checked.

Here is more information on how to get more than 64 threads working in parallel.

Maximum workers when multiprocessing in Python on Windows 10

This is a Windows specific limit, tied to the MAXIMUM_WAIT_OBJECTS limit of WaitForMultipleObjects (the limit is 64); you can see in your traceback that the ultimate problem is the call to _winapi.WaitForMultipleObjects; that's Windows-specific code. On Linux you should have no such problems.

There are ways around this limit (it basically involves creating nested hierarchies of handles to wait on), but it's complicated and has limitations; clearly the Python level code hasn't bothered to make use of any of these workarounds. Within Python, I think you're stuck using multiple pools if you want to exceed the limit. Since the limit is on how many handles can be monitored in a single call to WaitForMultipleObjects, not a limit on total processes, multiple pools should work just fine.

C++ windows threading and mutex issue

In the documentation for WaitForMultipleObjects, "The maximum number of object handles is MAXIMUM_WAIT_OBJECTS.", which is 64 on most systems.

This is also (almost) a duplicate of this thread. The summary is really just that yes, the limit is 64, and also to use the information in the remarks section of WaitForMultipleObjects to build up a tree of threads to wait on.

---

Related Topics