469,271 Members | 1,110 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,271 developers. It's quick & easy.

When can WaitForSingleObject return WAIT_FAILED?

When both waiting on an event and a simple unnamed mutex, I'm wondering
when WaitForSingleObject might return WAIT_FAILED. These are both
execution paths I'd very much like to avoid exceptional behavior but I
haven't found much documentation on the specifics. Can anyone offer advice?

Sean

Nov 17 '05 #1
6 10930
Sean Kelly <ke****@pacbell.net> wrote in message
news:uL**************@TK2MSFTNGP12.phx.gbl...
When both waiting on an event and a simple unnamed mutex, I'm wondering
when WaitForSingleObject might return WAIT_FAILED. These are both
execution paths I'd very much like to avoid exceptional behavior but I
haven't found much documentation on the specifics. Can anyone offer

advice?

Well, suppose you pass an invalid handle to the function? I'd expect that
you will get a WAIT_FAILED status and then INVALID_HANDLE in the call to
GetLastError(). I don't think there is any way you can avoid checking the
status of the code _somewhere_.

Regards,
Will
Nov 17 '05 #2
William DePalo wrote:
Sean Kelly <ke****@pacbell.net> wrote in message
news:uL**************@TK2MSFTNGP12.phx.gbl...
When both waiting on an event and a simple unnamed mutex, I'm wondering
when WaitForSingleObject might return WAIT_FAILED. These are both
execution paths I'd very much like to avoid exceptional behavior but I
haven't found much documentation on the specifics. Can anyone offer


advice?

Well, suppose you pass an invalid handle to the function? I'd expect that
you will get a WAIT_FAILED status and then INVALID_HANDLE in the call to
GetLastError(). I don't think there is any way you can avoid checking the
status of the code _somewhere_.


This is in an object and ensapsulation ensures that the parameters
passed will always be valid. Basically, I'm trying to avoid the
possibility that an exception may be thrown when acquiring a lock on a
mutex. Critical section operations are guranteed to succeed for this
reason. More info: it's an unnamed mutex without any security
restrictions. Basically, just an object that creates the mutex on
construction, locks/unlocks the mutex when requested, and destroys the
mutex on destruction. What I'm looking for is someone with enough
knowledge of the inner workings of the call that they could tell be what
conditions might cause a WAIT_FAILED in this instance. I'm hoping that
if I can satisfy enough preconditions before calling the function I can
be guranteed that the function will never fail in this way.

Sean

Nov 17 '05 #3
Sean Kelly <ke****@pacbell.net> wrote in message
news:uK**************@TK2MSFTNGP11.phx.gbl...
This is in an object and ensapsulation ensures that the parameters
passed will always be valid.
In an environment where "naked" pointers are used, memory corruption is not
impossible, encapsulation be damned. It is hard to imagine a Win32 program
without a single naked pointer.
What I'm looking for is someone with enough
knowledge of the inner workings of the call that they could tell be what
conditions might cause a WAIT_FAILED in this instance.
Then I suggest that you post again in the kernel group. Perhaps there you'll
run into someone who has seen the source or reverse engineered it.
I'm hoping that if I can satisfy enough preconditions
before calling the function I can be guranteed that
the function will never fail in this way.


Good luck.

Regards,
Will
Nov 17 '05 #4
William DePalo [MVP VC++] wrote:
Sean Kelly <ke****@pacbell.net> wrote in message
news:uK**************@TK2MSFTNGP11.phx.gbl...
This is in an object and ensapsulation ensures that the parameters
passed will always be valid.


In an environment where "naked" pointers are used, memory corruption
is not impossible, encapsulation be damned. It is hard to imagine a
Win32 program without a single naked pointer.
What I'm looking for is someone with enough
knowledge of the inner workings of the call that they could tell be
what conditions might cause a WAIT_FAILED in this instance.


Then I suggest that you post again in the kernel group. Perhaps there
you'll run into someone who has seen the source or reverse engineered
it.


If you're waiting on a mutex, you'll normally get WAIT_FAILED for only two
reasons: 1. The HANDLE you passed in is invalid. 2. Another thread that
owned the mutex was terminated without releasing ownership.

There's no guarantee that those are the only two circumstances though.
There are probably other, extremely rare and esoteric failures possible.

-cd
Nov 17 '05 #5
Carl Daniel [VC++ MVP] wrote:

If you're waiting on a mutex, you'll normally get WAIT_FAILED for only two
reasons: 1. The HANDLE you passed in is invalid. 2. Another thread that
owned the mutex was terminated without releasing ownership.
From what I read in MSDN I thought that case 2 would return
WAIT_ABANDONED and mutex ownership would be transferred.
There's no guarantee that those are the only two circumstances though.
There are probably other, extremely rare and esoteric failures possible.


That's what I'm afraid of. Worst case I suppose I can just always use
critical sections to avoid the possibility of failure.

Sean

Nov 17 '05 #6
Sean Kelly wrote:
Carl Daniel [VC++ MVP] wrote:

If you're waiting on a mutex, you'll normally get WAIT_FAILED for
only two reasons: 1. The HANDLE you passed in is invalid. 2.
Another thread that owned the mutex was terminated without releasing
ownership.


From what I read in MSDN I thought that case 2 would return
WAIT_ABANDONED and mutex ownership would be transferred.


You're right about that.

-cd
Nov 17 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

4 posts views Thread by izik l | last post: by
5 posts views Thread by ramialhasan | last post: by
1 post views Thread by stefan.sedich | last post: by
10 posts views Thread by blisspikle | last post: by
1 post views Thread by CARIGAR | last post: by
reply views Thread by zhoujie | last post: by
reply views Thread by suresh191 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.