Hi,
do we have a way to know which object has signaled while we are in KeWaitForMultipleObjects ? KeWaitForMultipleObjects can wait multiple objects as name indicates, but how can it distinguish which was the actual event ?
For ex, the user mode WAIT_OBJECT_0( or n-1 ) is one of the return values so that the user knows which event has been invoked.
If there is no direct way, what other way ( or combination ) can I use to know which object has been signaled?
Thanks
STATUS_WAIT_0 through STATUS_WAIT_63
Mark Roddy
On Sun, Feb 27, 2011 at 9:36 PM, wrote:
> Hi,
>
> do we have a way to know which object has signaled while we are in KeWaitForMultipleObjects ? ?KeWaitForMultipleObjects can wait multiple objects as name indicates, but how can it distinguish which was the actual event ?
>
> For ex, the user mode WAIT_OBJECT_0( or n-1 ) is one of the return values so that the user knows which event has been invoked.
>
> If there is no direct way, what other way ( or combination ) can I use to know which object has been signaled?
>
> Thanks
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>
Ha… Thanks Mark.
I was looking at a different help file… Just verified with the latest WDK help.
FYI this information is inherently ephemeral and usually of limited or no
value because any number of additional wait handles may also be in the
signalled state when the call returns. Unless the information is used as
indicative, or there is some other mechanism to synchronize the signalling
(al la lock ladders), relying on this value is a disaster waiting to happen.
wrote in message news:xxxxx@ntdev…
Ha… Thanks Mark.
I was looking at a different help file… Just verified with the latest WDK
help.
Um er, no it isn’t. If you specified WaitAny it is guaranteed that the
return value matches one of the signaled objects. It would be a
mistake to believe that this is the only signaled object. Perhaps that
is what you meant?
Mark Roddy
On Mon, Feb 28, 2011 at 6:56 PM, m wrote:
> FYI this information is inherently ephemeral and usually of limited or no
> value because any number of additional wait handles may also be in the
> signalled state when the call returns. ?Unless the information is used as
> indicative, or there is some other mechanism to synchronize the signalling
> (al la lock ladders), relying on this value is a disaster waiting to happen.
>
> wrote in message news:xxxxx@ntdev…
>
> Ha… Thanks Mark.
>
> I was looking at a different help file… Just verified with the latest WDK
> help.
>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
Exactly so.
If the wait is ‘wait all’ than the return value has no meaning inherently;
but if it is ‘wait any’ then it also has no meaning because it is merely one
of n signalled objects. In the first case, all of the objects must be
signalled, at least at an instant, so the value is arbitrary. And in the
second case, the value is arbitrary among the signalled objects so that the
simple logic of determining which one was signalled is fallacious. I
agree that correctly handled, it can be useful, but submit that the trivial
usage is incorrect
“Mark Roddy” wrote in message news:xxxxx@ntdev…
Um er, no it isn’t. If you specified WaitAny it is guaranteed that the
return value matches one of the signaled objects. It would be a
mistake to believe that this is the only signaled object. Perhaps that
is what you meant?
Mark Roddy
On Mon, Feb 28, 2011 at 6:56 PM, m wrote:
> FYI this information is inherently ephemeral and usually of limited or no
> value because any number of additional wait handles may also be in the
> signalled state when the call returns. Unless the information is used as
> indicative, or there is some other mechanism to synchronize the signalling
> (al la lock ladders), relying on this value is a disaster waiting to
> happen.
>
> wrote in message news:xxxxx@ntdev…
>
> Ha… Thanks Mark.
>
> I was looking at a different help file… Just verified with the latest WDK
> help.
>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
Exactly so.
If the wait is ‘wait all’ than the return value has no meaning
inherently;
but if it is ‘wait any’ then it also has no meaning because it is
merely one
of n signalled objects. In the first case, all of the objects must be
signalled, at least at an instant, so the value is arbitrary. And in
the
second case, the value is arbitrary among the signalled objects so
that the
simple logic of determining which one was signalled is fallacious.
I
agree that correctly handled, it can be useful, but submit that the
trivial
usage is incorrect
That might be true for a NotificationEvent, where it doesn’t actually
matter which event triggered it as any of the other events could have
been set subsequently anyway. For a SynchronizationEvent though, won’t
KeWaitForMultipleObjects(WaitAny) be satisfied by exactly one event
which will have then been reset atomically? The return value becomes
very meaningful in that case.
James
The documentation I have on KeWaitForMultipleObjects is obscure, misleading,
and contradictory. Either it returns STATUS_SUCCESS or it returns the index
of an element, but it can’t return both, as the documentation suggests.
In user space, WaitForMultipleObjects returns an integer which is the index
into the array of the first element which has been signaled, that is, the
lowest-numbered index in the array. It is not arbitrary, or meaningless.
So I’d suspect that documentation of KeWaitForMultipleObjects is FUBARed
Note that this gives some inherent prioritization to events. It also means
that you can potentially have one event mask every other possible event; the
usual paradigm is to remove that lowest-indexed value, shift everything down
by 1, and wait again; this means that the meaning of exiting the wait keeps
changing. What used to be event k is now event k-1, which is why
WaitForMultipleObjects is not nearly as useful as people like to pretend it
might be. In the best of all worlds, if you are doing wait-for-any, it is
with a compile-time-constant number of elements in the array, and they are
in order of their importance, where the fact that element n is signaled is
allowed to mask the fact that any number of elements k, for k > n, might
also be signaled.
joe
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of m
Sent: Tuesday, March 01, 2011 8:33 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] which object is signaled in KeWaitForMultipleObjects ?
Exactly so.
If the wait is ‘wait all’ than the return value has no meaning inherently;
but if it is ‘wait any’ then it also has no meaning because it is merely one
of n signalled objects. In the first case, all of the objects must be
signalled, at least at an instant, so the value is arbitrary. And in the
second case, the value is arbitrary among the signalled objects so that the
simple logic of determining which one was signalled is fallacious. I
agree that correctly handled, it can be useful, but submit that the trivial
usage is incorrect
“Mark Roddy” wrote in message news:xxxxx@ntdev…
Um er, no it isn’t. If you specified WaitAny it is guaranteed that the
return value matches one of the signaled objects. It would be a
mistake to believe that this is the only signaled object. Perhaps that
is what you meant?
Mark Roddy
On Mon, Feb 28, 2011 at 6:56 PM, m wrote:
> FYI this information is inherently ephemeral and usually of limited or no
> value because any number of additional wait handles may also be in the
> signalled state when the call returns. Unless the information is used as
> indicative, or there is some other mechanism to synchronize the signalling
> (al la lock ladders), relying on this value is a disaster waiting to
> happen.
>
> wrote in message news:xxxxx@ntdev…
>
> Ha… Thanks Mark.
>
> I was looking at a different help file… Just verified with the latest WDK
> help.
>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
–
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Joseph M. Newcomer wrote:
The documentation I have on KeWaitForMultipleObjects is obscure, misleading,
and contradictory. Either it returns STATUS_SUCCESS or it returns the index
of an element, but it can’t return both, as the documentation suggests.
It is not contradictory. It returns STATUS_SUCCESS only if you told it
to “wait for ALL” and all of them completed. What else would you have
it do in that case?
In user space, WaitForMultipleObjects returns an integer which is the index
into the array of the first element which has been signaled, that is, the
lowest-numbered index in the array.
You are just being silly. KeWaitForMultipleObjects and
WaitForMultipleObjects return EXACTLY the same success codes under the
same conditions. If you wait for all, and all events were satisfied,
both APIs return 0. If you wait for one, both return the index of the
item that completed.
Perhaps you are being misdirected by the fact that STATUS_SUCCESS and
STATUS_WAIT_0 and WAIT_OBJECT_0 all happen to have the numeric value 0.
So I’d suspect that documentation of KeWaitForMultipleObjects is FUBARed
I’d suspect that you are reading something that isn’t there.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
I’m not sure that this paradigm is a best case scenario. IMHO WFMO is most
useful when either of the following is true (using UM examples)
That the return value might indicate the lowest index that satisfied the
wait my no means implies that by the time the function returns other objects
with lower index values aren’t signalled is the basic problem
“Joseph M. Newcomer” wrote in message news:xxxxx@ntdev…
The documentation I have on KeWaitForMultipleObjects is obscure, misleading,
and contradictory. Either it returns STATUS_SUCCESS or it returns the index
of an element, but it can’t return both, as the documentation suggests.
In user space, WaitForMultipleObjects returns an integer which is the index
into the array of the first element which has been signaled, that is, the
lowest-numbered index in the array. It is not arbitrary, or meaningless.
So I’d suspect that documentation of KeWaitForMultipleObjects is FUBARed
Note that this gives some inherent prioritization to events. It also means
that you can potentially have one event mask every other possible event; the
usual paradigm is to remove that lowest-indexed value, shift everything down
by 1, and wait again; this means that the meaning of exiting the wait keeps
changing. What used to be event k is now event k-1, which is why
WaitForMultipleObjects is not nearly as useful as people like to pretend it
might be. In the best of all worlds, if you are doing wait-for-any, it is
with a compile-time-constant number of elements in the array, and they are
in order of their importance, where the fact that element n is signaled is
allowed to mask the fact that any number of elements k, for k > n, might
also be signaled.
joe
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of m
Sent: Tuesday, March 01, 2011 8:33 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] which object is signaled in KeWaitForMultipleObjects ?
Exactly so.
If the wait is ‘wait all’ than the return value has no meaning inherently;
but if it is ‘wait any’ then it also has no meaning because it is merely one
of n signalled objects. In the first case, all of the objects must be
signalled, at least at an instant, so the value is arbitrary. And in the
second case, the value is arbitrary among the signalled objects so that the
simple logic of determining which one was signalled is fallacious. I
agree that correctly handled, it can be useful, but submit that the trivial
usage is incorrect
“Mark Roddy” wrote in message news:xxxxx@ntdev…
Um er, no it isn’t. If you specified WaitAny it is guaranteed that the
return value matches one of the signaled objects. It would be a
mistake to believe that this is the only signaled object. Perhaps that
is what you meant?
Mark Roddy
On Mon, Feb 28, 2011 at 6:56 PM, m wrote:
> FYI this information is inherently ephemeral and usually of limited or no
> value because any number of additional wait handles may also be in the
> signalled state when the call returns. Unless the information is used as
> indicative, or there is some other mechanism to synchronize the signalling
> (al la lock ladders), relying on this value is a disaster waiting to
> happen.
>
> wrote in message news:xxxxx@ntdev…
>
> Ha… Thanks Mark.
>
> I was looking at a different help file… Just verified with the latest WDK
> help.
>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
–
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Generally, I find people who are using WFMO if the number of events is not a
compile-time constant end up creating unmaintainable messes. For example,
the situation where there are multiple inputs signaled means that one object
being signaled can permanently mask all higher-indexed objects being
signaled (one solution to this is upon each completion to “rotate” the
elements in the array, providing an illusion of fairness). I tend to
discourage WFMO except in the case where the 0th element means “shut down,
and I mean RIGHT NOW, and if there is pending input, too bad, it loses”,
which turns out to actually be a useful case.
Otherwise, there are far better solutions than WFMO. It is highly-unsuited,
for example, for waiting for multiple I/O event completion; the code rapidly
becomes convoluted as the handle is removed, and the event-index-to-response
mapping has to be updated, and new handles have to be added, etc. which is
why I believe that if the handles are not a compile-time-known-constant
number of objects in a fixed, predetermined, and guaranteed-robust order,
then the whole design is just wrong.
joe
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of m
Sent: Wednesday, March 02, 2011 8:42 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] which object is signaled in KeWaitForMultipleObjects ?
I’m not sure that this paradigm is a best case scenario. IMHO WFMO is most
useful when either of the following is true (using UM examples)
That the return value might indicate the lowest index that satisfied the
wait my no means implies that by the time the function returns other objects
with lower index values aren’t signalled is the basic problem
“Joseph M. Newcomer” wrote in message news:xxxxx@ntdev…
The documentation I have on KeWaitForMultipleObjects is obscure, misleading,
and contradictory. Either it returns STATUS_SUCCESS or it returns the index
of an element, but it can’t return both, as the documentation suggests.
In user space, WaitForMultipleObjects returns an integer which is the index
into the array of the first element which has been signaled, that is, the
lowest-numbered index in the array. It is not arbitrary, or meaningless.
So I’d suspect that documentation of KeWaitForMultipleObjects is FUBARed
Note that this gives some inherent prioritization to events. It also means
that you can potentially have one event mask every other possible event; the
usual paradigm is to remove that lowest-indexed value, shift everything down
by 1, and wait again; this means that the meaning of exiting the wait keeps
changing. What used to be event k is now event k-1, which is why
WaitForMultipleObjects is not nearly as useful as people like to pretend it
might be. In the best of all worlds, if you are doing wait-for-any, it is
with a compile-time-constant number of elements in the array, and they are
in order of their importance, where the fact that element n is signaled is
allowed to mask the fact that any number of elements k, for k > n, might
also be signaled.
joe
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of m
Sent: Tuesday, March 01, 2011 8:33 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] which object is signaled in KeWaitForMultipleObjects ?
Exactly so.
If the wait is ‘wait all’ than the return value has no meaning inherently;
but if it is ‘wait any’ then it also has no meaning because it is merely one
of n signalled objects. In the first case, all of the objects must be
signalled, at least at an instant, so the value is arbitrary. And in the
second case, the value is arbitrary among the signalled objects so that the
simple logic of determining which one was signalled is fallacious. I
agree that correctly handled, it can be useful, but submit that the trivial
usage is incorrect
“Mark Roddy” wrote in message news:xxxxx@ntdev…
Um er, no it isn’t. If you specified WaitAny it is guaranteed that the
return value matches one of the signaled objects. It would be a
mistake to believe that this is the only signaled object. Perhaps that
is what you meant?
Mark Roddy
On Mon, Feb 28, 2011 at 6:56 PM, m wrote:
> FYI this information is inherently ephemeral and usually of limited or no
> value because any number of additional wait handles may also be in the
> signalled state when the call returns. Unless the information is used as
> indicative, or there is some other mechanism to synchronize the signalling
> (al la lock ladders), relying on this value is a disaster waiting to
> happen.
>
> wrote in message news:xxxxx@ntdev…
>
> Ha… Thanks Mark.
>
> I was looking at a different help file… Just verified with the latest WDK
> help.
>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
–
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
–
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.