Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

WaitForMultipleObjects bug???

0 views
Skip to first unread message

Henry

unread,
Dec 28, 2000, 4:38:17 PM12/28/00
to
I have a multithreaded VC++ application. Each thread is created via the
_beginthread call. For each returned threadID from the _beginthread call,
I create an event handle for it. The event handle will signal when the
thread exits. So I have an array of handles. After spawning all the
threads, I finally make a call to WaitForMultipleObjects with the number of
threads spawned, the array of handles, and set the bWaitAll parameter to
true.

The WaitForMultipleObjects correctly returns when all threads have exited as
long as the threads are less than 65. Once I spawn 65 or more, the
WaitForMultipleObjects returns immediately as if every handle was signaled
but the threads still have not finished which I verified. Is this a big in
WaitForMultipleObjects? Thanks.


Jason Terando

unread,
Dec 28, 2000, 4:56:23 PM12/28/00
to
There might be a clue in the return value of the function, or, if its
WAIT_FAILED, in GetLastError().

Prepare for "off-topic" flames.

"Henry" <hl...@ncommand.net> wrote in message
news:OQ3lbaRcAHA.1924@tkmsftngp05...

Henry

unread,
Dec 28, 2000, 5:53:52 PM12/28/00
to
Good point. I acutally got a return value of WAIT_FAILED and the
GetLastError was "The parameter was incorrect." This is especially strange
since no problems occur with less than 65 thread handles. Any ideas?

"Jason Terando" <jasont_...@rapidtext.com> wrote in message
news:egj5PiRcAHA.2216@tkmsftngp02...

Jason Terando

unread,
Dec 28, 2000, 6:56:18 PM12/28/00
to
Check out KB article Q271993, apparently, you are limited to 64 handles.

"Henry" <hl...@ncommand.net> wrote in message

news:O6IQqEScAHA.1956@tkmsftngp05...

Jan Bares

unread,
Dec 29, 2000, 5:22:10 AM12/29/00
to
As the documentation states, The maximum number of object handles is
MAXIMUM_WAIT_OBJECTS.
#define MAXIMUM_WAIT_OBJECTS 64 // Maximum number of wait objects

This is the upper limit. Jeffrey Richter has an article in MSJ about this
topic and solution. Unfortunately I cannot find it. Someone else will help?

Regards, Jan
--

Jan Bares
(remove no.spam from my email address)
JPCAD Graphics Engine developer, surf to http://www.antek.cz


"Henry" <hl...@ncommand.net> wrote in message
news:OQ3lbaRcAHA.1924@tkmsftngp05...

Jason Terando

unread,
Dec 29, 2000, 12:39:20 PM12/29/00
to
Maybe could could make a counter and wrap a mutex around it? Increment when
a thread is created, have the threads decrement it when they close. When it
gets to zero, signal an event.

"Jan Bares" <jan....@antek.cz.no.spam> wrote in message
news:udcy2EYcAHA.2108@tkmsftngp05...

Henry

unread,
Jan 2, 2001, 3:38:26 PM1/2/01
to
Thanks for the help Jason. You're right about using a counter. I used to
do that but did not want to have to write a polling routine to constantly
check for the counter to become zero. I guess I have to. Thanks.

/henry

"Jason Terando" <jasont_...@rapidtext.com> wrote in message

news:OHB2S3bcAHA.452@tkmsftngp02...

Igor Tandetnik

unread,
Jan 2, 2001, 4:17:59 PM1/2/01
to
You can have a mutex, a counter and an event. When the counter goes from 0
to 1, you reset the event. When the counter goes from 1 to 0, you signal the
event. This way, instead of polling, you can wait on an event.
--
With best wishes,
Igor Tandetnik

"Henry" <hl...@ncommand.net> wrote in message

news:u2jeVwPdAHA.2184@tkmsftngp05...

Reginald Blue

unread,
Jan 2, 2001, 4:44:05 PM1/2/01
to
Two things:

1. It's not necessary to create an event to signal completion if you use
beginthreadex and wait on the thread handle to terminate. (i.e. it behaves
exactly like your event. It becomes signalled when the thread terminates).

2. The last time I did this, I built a temporary array of 64 handles,
waited on all of those, then did the next 64, until I ran out of handles and
I knew I was done. So, at most, you have n Threads/64 loops to process
(where 'n' is the total number of threads you started). Also you can use
"WaitForSingle..." with a delay of 0 to determine if a particular handle
needs to be waited on at all (i.e. if it's already signalled you don't have
to wait for it.)

HTH

--
Reginald Blue | Opinions expressed here do not
Natural Language Understanding | necessarily represent those of
Unisys Corporation | my employer.
--------------------------------+-------------------------------
For speech technology solutions,| r...@NOSPAM.trsvr.tr.unisys.com
NL technology,speech application| My email address is wrong, you
development training, see: | need to remove the obvious.
http://www.speechdepot.com/ +-------------------------------


"Henry" <hl...@ncommand.net> wrote in message

news:u2jeVwPdAHA.2184@tkmsftngp05...


> Thanks for the help Jason. You're right about using a counter. I used to
> do that but did not want to have to write a polling routine to constantly
> check for the counter to become zero. I guess I have to. Thanks.

0 new messages