dotnet clr: WaitHandles must be less than or equal to 64 - missing documentation -- dotnet clr

RE: WaitHandles must be less than or equal to 64 - missing documentati

Peter Ritchie [C# MVP]
12/24/2006 5:10:00 PM

In .NET 2.0 it's simply hard coded to 64. This is based upon the limit of
object handles that the Win32 function WaitForMultipleObjectsEx can
support--which is documented as being MAXIMUM_WAIT_OBJECTS, or 64.

If you want to wait for more than 64 handles you'll have to break it into
chunks of 64 and create a thread for each <=64 chunk that sets another
WaitHandle that is waited upon in some "main" thread (can't be the main
thread in a WinForms application)--which would give you the ability to wait
on 64 blocks of 64 wait handles. More than that and you'd have to break out
to 3 levels. I think there's an example or two on the web of handling more
than 64 handles...

--
Browse http://connect.microsoft.com/VisualStudio/feedback/ and vote.
http://www.peterRitchie.com/blog/
Microsoft MVP, Visual Developer - Visual C#

[quoted text, click to view]

Re: WaitHandles must be less than or equal to 64 - missing documentation

William Stacey [C# MVP]
12/24/2006 10:06:39 PM

Fortunately, WaitAll is easy to implement with any number of handles. Here
is a simple example.

public static void WaitAll(WaitHandle[] handles)
{
if (handles == null)
throw new ArgumentNullException("handles");
foreach (WaitHandle wh in handles)
{
wh.WaitOne();
}
}

--
William Stacey [C# MVP]

[quoted text, click to view]
| Calling WaitAll with array of 64 or more causes exception
| WaitHandle.WaitAll(whaWaitHandlesArray);
|
| System.NotSupportedException: The number of WaitHandles must be less
| than or equal to 64.
| at System.Threading.WaitHandle.WaitAll(WaitHandle[] waitHandles,
| Int32 millisecondsTimeout, Boolean exitContext)
| at System.Threading.WaitHandle.WaitAll(WaitHandle[] waitHandles)
|
| Searching for the error string revealed no KB article or MSDN
| documentation.
| I did found MSFT answer regarding that on:
|
http://groups.google.com/group/microsoft.public.sqlserver.notificationsvcs/tree/browse_frm/thread/1e10fc93cf194775/1d8e7ee0e1a3f41c
|
| The API documentation says it might throw NotSupportedException under
| the condition: "The number of objects in waitHandles is greater than
| the system permits."
|
| My questions are:
| 1. How can I find the system limitation? what does it depends on?
| 2. Any kb article that will provide link from the exception message to
| the real cause will be helpful for all the developers and will save us
| google time
|
| (About Google Vs www.Live.com - Live did not find even a single match
| ...)
|
| Loy
|

Re: WaitHandles must be less than or equal to 64 - missing documentation

Ben Voigt
12/26/2006 2:30:45 PM

[quoted text, click to view]

Which does not replicate the proper semantics and therefore is vulnerable to
deadlock.

[quoted text, click to view]

Re: WaitHandles must be less than or equal to 64 - missing documentation

Ben Voigt
12/26/2006 2:31:53 PM

[quoted text, click to view]

At this point you should re-architect your application to use fewer wait
handles. What kind of object are you waiting on and why do you need so
many?

[quoted text, click to view]

Re: WaitHandles must be less than or equal to 64 - missing documen

Peter Ritchie [C# MVP]
12/26/2006 6:30:00 PM

My calling WaitOne in a loop like that you're allowing the thread to gain
ownership of a WaitHandle without having ownership of all WaitHandles.
WaitAll does not give ownership of all WaitHandes until all WaitHandles have
entered a signaled state.

WaitAll can be given a timeout, if that timeout expires before all
WaitHandles are signaled the thread never gains ownership of any of the
WaitHandles even if some of them have signaled.

BTW, you'd have this same problem if had to split up more thane 64
WaitHandles across multiple threads with multiple calls to WaitAll...

--
Browse http://connect.microsoft.com/VisualStudio/feedback/ and vote.
http://www.peterRitchie.com/blog/
Microsoft MVP, Visual Developer - Visual C#

[quoted text, click to view]

Re: WaitHandles must be less than or equal to 64 - missing documentation

William Stacey [C# MVP]
12/26/2006 7:37:16 PM

How so?

--
William Stacey [C# MVP]

[quoted text, click to view]
| > Fortunately, WaitAll is easy to implement with any number of handles.
| > Here
| > is a simple example.
|
| Which does not replicate the proper semantics and therefore is vulnerable
to
| deadlock.

Re: WaitHandles must be less than or equal to 64 - missing documen

William Stacey [C# MVP]
12/27/2006 12:26:19 AM

This can get slightly more involved and depends on the handle type. If the
wait events are ManualResetEvents, then a timeout may not matter to your
code as they stay signaled anyway. AutoResetEvents are more an issue as
some may be reset by the WaitOne() call before the timeout and that could
get messy - but can still be workable depending on needs. Semaphores,
however, do change their state even with the win32 waitformultipleobjects as
it waits for each one in turn (so the net effect would be the same as using
the shown implementation). If one understands the potential issues and
takes care, the pattern can prove useful when waiting on many handles.

--
William Stacey [C# MVP]

[quoted text, click to view]
| My calling WaitOne in a loop like that you're allowing the thread to gain
| ownership of a WaitHandle without having ownership of all WaitHandles.
| WaitAll does not give ownership of all WaitHandes until all WaitHandles
have
| entered a signaled state.
|
| WaitAll can be given a timeout, if that timeout expires before all
| WaitHandles are signaled the thread never gains ownership of any of the
| WaitHandles even if some of them have signaled.
|
| BTW, you'd have this same problem if had to split up more thane 64
| WaitHandles across multiple threads with multiple calls to WaitAll...
|
| --
| Browse http://connect.microsoft.com/VisualStudio/feedback/ and vote.
| http://www.peterRitchie.com/blog/
| Microsoft MVP, Visual Developer - Visual C#
|
|
[quoted text, click to view]
|
| > How so?
| >
| > --
| > William Stacey [C# MVP]
| >
[quoted text, click to view]
| > | > Fortunately, WaitAll is easy to implement with any number of
handles.
| > | > Here
| > | > is a simple example.
| > |
| > | Which does not replicate the proper semantics and therefore is
vulnerable
| > to
| > | deadlock.
| >
| >
| >

Re: WaitHandles must be less than or equal to 64 - missing documen

Loy
12/27/2006 4:33:06 AM

Thank you all for your reply

I implemented the simple workaround with the limitation that it works
only if the handles are not reset again during the wait time.

In my case this is a valid limitation as I wait for objects to close
and the handle is nullified in the objects once it is set.

Being aware of this issue - if there is a correct implementation - why
doesn't the dot net team implement it as part of the framework?

On the documentation side - Need to be clear on how to know your system
limitation
A kb article is the least that I would expect with regard to this
issue.

Am I wrong?

Thanks

Loy

[quoted text, click to view]

Re: WaitHandles must be less than or equal to 64 - missing documentation

Ben Voigt
12/27/2006 5:04:09 PM

[quoted text, click to view]

I think Peter has done a fantastic job of explaining why this is so. If you
still aren't convinced there is a significant difference between:

WaitForMultipleObjects({A, B, C, D});
and
WaitForSingleObject(A);WaitForSingle(B);WaitForSingle(C);WaitForSingle(D);

then I will be happy to clarify.

[quoted text, click to view]

Re: WaitHandles must be less than or equal to 64 - missing documentation

William Stacey [C# MVP]
12/28/2006 4:43:49 PM

| I think Peter has done a fantastic job of explaining why this is so.

Totally agree.

| still aren't convinced there is a significant difference between:
|
| WaitForMultipleObjects({A, B, C, D});
| and
| WaitForSingleObject(A);WaitForSingle(B);WaitForSingle(C);WaitForSingle(D);
|
| then I will be happy to clarify.

Thanks Ben. Not sure there is any confusion on that. I think we/I
meandered into some different areas. All is good. Happy New Year.

--
William Stacey [C# MVP]

Got something to say? Click here to post a reply to this thread.

Don't see what you're looking for? Try a search.

View other messages in the dotnet clr group.