开发者

WaitAll limitation

开发者 https://www.devze.com 2023-01-25 01:32 出处:网络
I heard there is limitation when using waitallon multiple threads 开发者_如何学编程(# of threads to wait?). Can anyone give details?I think the restriction you are referring to is not on the number of

I heard there is limitation when using waitall on multiple threads 开发者_如何学编程(# of threads to wait?). Can anyone give details?


I think the restriction you are referring to is not on the number of threads; it is on the number of handles being waited on. From the MSDN page for WaitHandle.WaitAll(WaitHandle[]):

On some implementations, if more than 64 handles are passed, a NotSupportedException is thrown.

On the rare occasion that this issue has cropped, I have normally worked around it with:

WaitHandle[] handles = ...

foreach(var waitHandle in handles)
   waitHandle.WaitOne();

For completeness, the other restrictions appear to be:

If the array contains duplicates, the call fails with a DuplicateWaitObjectException.

The WaitAll method is not supported on threads that have STAThreadAttribute.


Are you thinking of the STA (single-threaded apartment) limitation of a winform app?

If so, I handle this by simply checking if the 'work queue' is empty after each thread has done it's processing, and calling .WaitOne() on a single ManualResetEvent object that the main thread owns instead of using .WaitAll() at all.

Like this:

    moSolverEvent = new ManualResetEvent(false);
    ProcessResult(new SolverWorkInProgress());

    //Wait here until the last background thread reports in
    moSolverEvent.WaitOne();

And then the worker threads are doing this:

if (mhSolverWorkQueue.Count == 0) moSolverEvent.Set();

It works spectacularly well, and avoids any issues with WaitAll(), even in a WinForms app. After all, you're not really waiting for the threads to be done... you're waiting for the WORK to be done. :-)

Just be sure to do the appropriate locking on each of these objects so your threads don't step all over each other.

0

精彩评论

暂无评论...
验证码 换一张
取 消