Hello All,
I am confused about the DDK’s section “Do Waiting Threads Receive Alerts and
APCs?”. I checked some articles including “Locks Deadlocks and
syncronization” and some similar discussions in NTDEV and NTFSD but I am
still not sure I understand this correclty.
What I understand is that there exists a thread state that is called
“Alertable”. This state is an alternative to the normal “Waiting” thread
state.
If I understand correctly the difference between the the normal “Waiting”
thread state and the “Alertable_Waiting” thread state is:
(*) A thread waiting in the simple “Waiting” state enters the Ready/Running
state when the wait is satisfied (the objects KeWaitXX is waiting for are
signaled) or if it times out.
(*) A thread in the “Alertable_Waiting” state enters the Ready/Running state
when the wait is satisfied or times out, but also if the wait is Aborted. A
wait in the “Alertable_Waiting” state is aborted when an alert is received.
(also the wait is aborted when a user mode apc is received and the kewaitxxx
was called with waitmode=usermode and of course alertable=true)
My questions are the following:
- Is what I describe above correct Or have I completely missed the mark??
- How does a thread enter the alertable state? If I understand correclty a
thread is in an alertable state when it is blocked inside a KeWaitxxx which
was called with the Alertable parameter set to TRUE and the WaitMode
parameter set to either kernelmode or usermode. In other words WaitMode does
not play any role in whether the thread will enter the “alertable” state. Or
does it?
The DDK says: “If the value of this parameter (Alertable) is FALSE then the
thread cannot be alerted, no matter what the value of the WaitMode parameter
or the origin of the alert.”. But is does not say exactly what happens if
the Alertable parameter is TRUE. It just says: “The effects of the values
that can be assigned to these two parameters (Alertable and WaitMode) are
complex. Assigning a value of TRUE to the Alertable parameter, for instance,
does not guarantee that the waiting thread can be alerted.”. So should I
assume that specifying Alertable=TRUE is not enough for the thread to enter
the alertable state??
But then again the first two rows of the table in “Do waiting threads
receive…” (first row is the case for Alertable=TRUE and WaitMode=UserMode
second row is the case for Alertable=TRUE and WaitMode=KernelMode) shows in
the Alerts column that when the Alertable value is TRUE the wait is aborted
whatever the value of WaitMode. Doesn’t that imply that the thread was in
alertable state? (in order for the alert to be able to abort the wait). And
if it does imply that then doesn’t that mean that the alertable parameter is
enough by itself to determine if the thread is going to enter the alertable
wait state or a normal wait state??
- What is an alert, what’s the use of alerts?
As I understand it there is a need sometimes to ABORT a wait. And “sending
an alert” to a thread that is waiting in “alertable” state is the way to do
that.
Is this correct and if it is do you know a case when the OS needs to abort a
wait by sending an alert??
- The document “Locks Deadlocks and Synchronization” states in page 20
that:
“Driver routines should always specify KernelMode when they are waiting for
a kernel mutex. Waiting in kernel mode prevents the thread’s kernel-mode
stack from being paged out and disables the delivery of user-mode and normal
kernel-mode APCs, thus preventing thread termination and suspension. Special
kernel-mode APCs, such as the special kernel-mode APC for I/O completion,
can still be delivered.”.
But a table in the same document which is a copy of the table in the “Do
waiting threads receive alerts and APCs?” it shows that while a thread is
waiting with WaitMode=KernelMode then kernelmode APCs (normal or special)
are perfectly capable of being delivered as long as some conditions are
true. In exact it states that special kernel mode APCs are delivered if IRQL
< APC_LEVEL. And normal kernel mode APCs are delivered if IRQL < APC_LEVEL,
thread not already in an APC, thread not in a critical region.
So my last question is does a thread blocked inside a KeWaitXxx prevent
kernel mode apcs or not?
Sorry for the size of this question, I would appreciate it if someone would
take the time to read it and help me understand this.
Best regards,
Antonis
I recommend reading the paper about locks and synchronization at
http://www.microsoft.com/whdc/driver/kernel/default.mspx. There are also a
bunch of other useful papers there that might help.
–
Jake Oshins
Windows Kernel Group
This posting is provided “AS IS” with no warranties, and confers no rights.
“antonis” wrote in message news:xxxxx@ntdev…
> Hello All,
>
> I am confused about the DDK’s section “Do Waiting Threads Receive Alerts
> and
> APCs?”. I checked some articles including “Locks Deadlocks and
> syncronization” and some similar discussions in NTDEV and NTFSD but I am
> still not sure I understand this correclty.
>
> What I understand is that there exists a thread state that is called
> “Alertable”. This state is an alternative to the normal “Waiting” thread
> state.
> If I understand correctly the difference between the the normal “Waiting”
> thread state and the “Alertable_Waiting” thread state is:
> () A thread waiting in the simple “Waiting” state enters the
> Ready/Running
> state when the wait is satisfied (the objects KeWaitXX is waiting for are
> signaled) or if it times out.
> () A thread in the “Alertable_Waiting” state enters the Ready/Running
> state
> when the wait is satisfied or times out, but also if the wait is Aborted.
> A
> wait in the “Alertable_Waiting” state is aborted when an alert is
> received.
> (also the wait is aborted when a user mode apc is received and the
> kewaitxxx
> was called with waitmode=usermode and of course alertable=true)
>
> My questions are the following:
>
> 1) Is what I describe above correct Or have I completely missed the mark??
> 2) How does a thread enter the alertable state? If I understand correclty
> a
> thread is in an alertable state when it is blocked inside a KeWaitxxx
> which
> was called with the Alertable parameter set to TRUE and the WaitMode
> parameter set to either kernelmode or usermode. In other words WaitMode
> does
> not play any role in whether the thread will enter the “alertable” state.
> Or
> does it?
> The DDK says: “If the value of this parameter (Alertable) is FALSE then
> the
> thread cannot be alerted, no matter what the value of the WaitMode
> parameter
> or the origin of the alert.”. But is does not say exactly what happens if
> the Alertable parameter is TRUE. It just says: “The effects of the values
> that can be assigned to these two parameters (Alertable and WaitMode) are
> complex. Assigning a value of TRUE to the Alertable parameter, for
> instance,
> does not guarantee that the waiting thread can be alerted.”. So should I
> assume that specifying Alertable=TRUE is not enough for the thread to
> enter
> the alertable state??
> But then again the first two rows of the table in “Do waiting threads
> receive…” (first row is the case for Alertable=TRUE and
> WaitMode=UserMode
> second row is the case for Alertable=TRUE and WaitMode=KernelMode) shows
> in
> the Alerts column that when the Alertable value is TRUE the wait is
> aborted
> whatever the value of WaitMode. Doesn’t that imply that the thread was in
> alertable state? (in order for the alert to be able to abort the wait).
> And
> if it does imply that then doesn’t that mean that the alertable parameter
> is
> enough by itself to determine if the thread is going to enter the
> alertable
> wait state or a normal wait state??
> 3) What is an alert, what’s the use of alerts?
> As I understand it there is a need sometimes to ABORT a wait. And “sending
> an alert” to a thread that is waiting in “alertable” state is the way to
> do
> that.
> Is this correct and if it is do you know a case when the OS needs to abort
> a
> wait by sending an alert??
> 4) The document “Locks Deadlocks and Synchronization” states in page 20
> that:
> “Driver routines should always specify KernelMode when they are waiting
> for
> a kernel mutex. Waiting in kernel mode prevents the thread’s kernel-mode
> stack from being paged out and disables the delivery of user-mode and
> normal
> kernel-mode APCs, thus preventing thread termination and suspension.
> Special
> kernel-mode APCs, such as the special kernel-mode APC for I/O completion,
> can still be delivered.”.
> But a table in the same document which is a copy of the table in the “Do
> waiting threads receive alerts and APCs?” it shows that while a thread is
> waiting with WaitMode=KernelMode then kernelmode APCs (normal or special)
> are perfectly capable of being delivered as long as some conditions are
> true. In exact it states that special kernel mode APCs are delivered if
> IRQL
> < APC_LEVEL. And normal kernel mode APCs are delivered if IRQL <
> APC_LEVEL,
> thread not already in an APC, thread not in a critical region.
> So my last question is does a thread blocked inside a KeWaitXxx prevent
> kernel mode apcs or not?
>
> Sorry for the size of this question, I would appreciate it if someone
> would
> take the time to read it and help me understand this.
>
> Best regards,
> Antonis
>
>
>
Thank you for pointing me to it, but I have already read it and although it
cleared up a lot of things it also introduced one more question (this paper
is actually the source of my 4th question).
I will repeat my 4th question here for convinience:
In page 20 of this document it is stated that:
“Waiting in kernel mode … disables the delivery of user-mode and normal
kernel-mode APCs …”
In the same paper at the table about receiving APCs it is shown that while
waiting in kernelmode, normal kernel mode APCs are delivered and run.
So which of the two is correct?? (are normal kernel APC delivered or
not ->(are threads suspended or not))
Thanks again,
Antonis
“Jake Oshins” wrote in message
news:xxxxx@ntdev…
>I recommend reading the paper about locks and synchronization at
>http://www.microsoft.com/whdc/driver/kernel/default.mspx. There are also a
>bunch of other useful papers there that might help.
>
> –
> Jake Oshins
> Windows Kernel Group
>
> This posting is provided “AS IS” with no warranties, and confers no
> rights.
>
>
> “antonis” wrote in message news:xxxxx@ntdev…
>> Hello All,
>>
>> I am confused about the DDK’s section “Do Waiting Threads Receive Alerts
>> and
>> APCs?”. I checked some articles including “Locks Deadlocks and
>> syncronization” and some similar discussions in NTDEV and NTFSD but I am
>> still not sure I understand this correclty.
>>
>> What I understand is that there exists a thread state that is called
>> “Alertable”. This state is an alternative to the normal “Waiting” thread
>> state.
>> If I understand correctly the difference between the the normal “Waiting”
>> thread state and the “Alertable_Waiting” thread state is:
>> () A thread waiting in the simple “Waiting” state enters the
>> Ready/Running
>> state when the wait is satisfied (the objects KeWaitXX is waiting for are
>> signaled) or if it times out.
>> () A thread in the “Alertable_Waiting” state enters the Ready/Running
>> state
>> when the wait is satisfied or times out, but also if the wait is Aborted.
>> A
>> wait in the “Alertable_Waiting” state is aborted when an alert is
>> received.
>> (also the wait is aborted when a user mode apc is received and the
>> kewaitxxx
>> was called with waitmode=usermode and of course alertable=true)
>>
>> My questions are the following:
>>
>> 1) Is what I describe above correct Or have I completely missed the
>> mark??
>> 2) How does a thread enter the alertable state? If I understand
>> correclty a
>> thread is in an alertable state when it is blocked inside a KeWaitxxx
>> which
>> was called with the Alertable parameter set to TRUE and the WaitMode
>> parameter set to either kernelmode or usermode. In other words WaitMode
>> does
>> not play any role in whether the thread will enter the “alertable” state.
>> Or
>> does it?
>> The DDK says: “If the value of this parameter (Alertable) is FALSE then
>> the
>> thread cannot be alerted, no matter what the value of the WaitMode
>> parameter
>> or the origin of the alert.”. But is does not say exactly what happens
>> if
>> the Alertable parameter is TRUE. It just says: “The effects of the values
>> that can be assigned to these two parameters (Alertable and WaitMode) are
>> complex. Assigning a value of TRUE to the Alertable parameter, for
>> instance,
>> does not guarantee that the waiting thread can be alerted.”. So should I
>> assume that specifying Alertable=TRUE is not enough for the thread to
>> enter
>> the alertable state??
>> But then again the first two rows of the table in “Do waiting threads
>> receive…” (first row is the case for Alertable=TRUE and
>> WaitMode=UserMode
>> second row is the case for Alertable=TRUE and WaitMode=KernelMode) shows
>> in
>> the Alerts column that when the Alertable value is TRUE the wait is
>> aborted
>> whatever the value of WaitMode. Doesn’t that imply that the thread was in
>> alertable state? (in order for the alert to be able to abort the wait).
>> And
>> if it does imply that then doesn’t that mean that the alertable parameter
>> is
>> enough by itself to determine if the thread is going to enter the
>> alertable
>> wait state or a normal wait state??
>> 3) What is an alert, what’s the use of alerts?
>> As I understand it there is a need sometimes to ABORT a wait. And
>> “sending
>> an alert” to a thread that is waiting in “alertable” state is the way to
>> do
>> that.
>> Is this correct and if it is do you know a case when the OS needs to
>> abort a
>> wait by sending an alert??
>> 4) The document “Locks Deadlocks and Synchronization” states in page 20
>> that:
>> “Driver routines should always specify KernelMode when they are waiting
>> for
>> a kernel mutex. Waiting in kernel mode prevents the thread’s kernel-mode
>> stack from being paged out and disables the delivery of user-mode and
>> normal
>> kernel-mode APCs, thus preventing thread termination and suspension.
>> Special
>> kernel-mode APCs, such as the special kernel-mode APC for I/O completion,
>> can still be delivered.”.
>> But a table in the same document which is a copy of the table in the “Do
>> waiting threads receive alerts and APCs?” it shows that while a thread is
>> waiting with WaitMode=KernelMode then kernelmode APCs (normal or special)
>> are perfectly capable of being delivered as long as some conditions are
>> true. In exact it states that special kernel mode APCs are delivered if
>> IRQL
>> < APC_LEVEL. And normal kernel mode APCs are delivered if IRQL <
>> APC_LEVEL,
>> thread not already in an APC, thread not in a critical region.
>> So my last question is does a thread blocked inside a KeWaitXxx prevent
>> kernel mode apcs or not?
>>
>> Sorry for the size of this question, I would appreciate it if someone
>> would
>> take the time to read it and help me understand this.
>>
>> Best regards,
>> Antonis
>>
>>
>>
>
>
>
Also in the paper Jake Oshins recommends you look at the table 8: You see
that for User-mode APC Terminate is NO when Alertable = TRUE and WaitMode =
KernelMode. Now look at the DDK table 8: in “Do Waiting Threads Receive
Alerts and APCs” the same parameters for the table give YES! Do we have a
another contradiction!
Sincerely;
Mike Jones
“Jake Oshins” wrote in message
news:xxxxx@ntdev…
> I recommend reading the paper about locks and synchronization at
> http://www.microsoft.com/whdc/driver/kernel/default.mspx. There are also
a
> bunch of other useful papers there that might help.
>
> –
> Jake Oshins
> Windows Kernel Group
>
> This posting is provided “AS IS” with no warranties, and confers no
rights.
>
>
> “antonis” wrote in message news:xxxxx@ntdev…
> > Hello All,
> >
> > I am confused about the DDK’s section “Do Waiting Threads Receive Alerts
> > and
> > APCs?”. I checked some articles including “Locks Deadlocks and
> > syncronization” and some similar discussions in NTDEV and NTFSD but I am
> > still not sure I understand this correclty.
> >
> > What I understand is that there exists a thread state that is called
> > “Alertable”. This state is an alternative to the normal “Waiting” thread
> > state.
> > If I understand correctly the difference between the the normal
“Waiting”
> > thread state and the “Alertable_Waiting” thread state is:
> > () A thread waiting in the simple “Waiting” state enters the
> > Ready/Running
> > state when the wait is satisfied (the objects KeWaitXX is waiting for
are
> > signaled) or if it times out.
> > () A thread in the “Alertable_Waiting” state enters the Ready/Running
> > state
> > when the wait is satisfied or times out, but also if the wait is
Aborted.
> > A
> > wait in the “Alertable_Waiting” state is aborted when an alert is
> > received.
> > (also the wait is aborted when a user mode apc is received and the
> > kewaitxxx
> > was called with waitmode=usermode and of course alertable=true)
> >
> > My questions are the following:
> >
> > 1) Is what I describe above correct Or have I completely missed the
mark??
> > 2) How does a thread enter the alertable state? If I understand
correclty
> > a
> > thread is in an alertable state when it is blocked inside a KeWaitxxx
> > which
> > was called with the Alertable parameter set to TRUE and the WaitMode
> > parameter set to either kernelmode or usermode. In other words WaitMode
> > does
> > not play any role in whether the thread will enter the “alertable”
state.
> > Or
> > does it?
> > The DDK says: “If the value of this parameter (Alertable) is FALSE then
> > the
> > thread cannot be alerted, no matter what the value of the WaitMode
> > parameter
> > or the origin of the alert.”. But is does not say exactly what happens
if
> > the Alertable parameter is TRUE. It just says: “The effects of the
values
> > that can be assigned to these two parameters (Alertable and WaitMode)
are
> > complex. Assigning a value of TRUE to the Alertable parameter, for
> > instance,
> > does not guarantee that the waiting thread can be alerted.”. So should I
> > assume that specifying Alertable=TRUE is not enough for the thread to
> > enter
> > the alertable state??
> > But then again the first two rows of the table in “Do waiting threads
> > receive…” (first row is the case for Alertable=TRUE and
> > WaitMode=UserMode
> > second row is the case for Alertable=TRUE and WaitMode=KernelMode) shows
> > in
> > the Alerts column that when the Alertable value is TRUE the wait is
> > aborted
> > whatever the value of WaitMode. Doesn’t that imply that the thread was
in
> > alertable state? (in order for the alert to be able to abort the wait).
> > And
> > if it does imply that then doesn’t that mean that the alertable
parameter
> > is
> > enough by itself to determine if the thread is going to enter the
> > alertable
> > wait state or a normal wait state??
> > 3) What is an alert, what’s the use of alerts?
> > As I understand it there is a need sometimes to ABORT a wait. And
“sending
> > an alert” to a thread that is waiting in “alertable” state is the way to
> > do
> > that.
> > Is this correct and if it is do you know a case when the OS needs to
abort
> > a
> > wait by sending an alert??
> > 4) The document “Locks Deadlocks and Synchronization” states in page 20
> > that:
> > “Driver routines should always specify KernelMode when they are waiting
> > for
> > a kernel mutex. Waiting in kernel mode prevents the thread’s kernel-mode
> > stack from being paged out and disables the delivery of user-mode and
> > normal
> > kernel-mode APCs, thus preventing thread termination and suspension.
> > Special
> > kernel-mode APCs, such as the special kernel-mode APC for I/O
completion,
> > can still be delivered.”.
> > But a table in the same document which is a copy of the table in the “Do
> > waiting threads receive alerts and APCs?” it shows that while a thread
is
> > waiting with WaitMode=KernelMode then kernelmode APCs (normal or
special)
> > are perfectly capable of being delivered as long as some conditions are
> > true. In exact it states that special kernel mode APCs are delivered if
> > IRQL
> > < APC_LEVEL. And normal kernel mode APCs are delivered if IRQL <
> > APC_LEVEL,
> > thread not already in an APC, thread not in a critical region.
> > So my last question is does a thread blocked inside a KeWaitXxx prevent
> > kernel mode apcs or not?
> >
> > Sorry for the size of this question, I would appreciate it if someone
> > would
> > take the time to read it and help me understand this.
> >
> > Best regards,
> > Antonis
> >
> >
> >
>
>
>
Mike,
As far as I can see the tables are identical in the paper and in the ddk
(except for the alerts column that is missing in the paper). But if we are
talking about
ambiguity check this: Table 8. shows that when waiting with Alertable=False
WaitMode=UserMode, a usermode APC cannot terminate the wait. But the same
paper a couple of paragraphs down says:
" If a driver calls KeWaitForSingleObject or KeWaitForMultipleObjects with
WaitMode set to UserMode, but Alertable set to FALSE, the wait will abort
with STATUS_USER_APC if the thread is being terminated…"
So will the wait abort in that case or not? Applying some common sense would
lead me to believe that the wait will be aborted. But I cannot be sure, can
I?
Anyway I don’t mean to criticize the info published in whdc. I am actually
greatful for its existance, honest.
I would just like to have a clear picture of this APC/alert delivery stuff
so that I would not have to check that table(which by the way I am not sure
if it is correct) everytime.
Thanks,
Antonis
“Michael Jones” wrote in message
news:xxxxx@ntdev…
> Also in the paper Jake Oshins recommends you look at the table 8: You see
> that for User-mode APC Terminate is NO when Alertable = TRUE and WaitMode
> =
> KernelMode. Now look at the DDK table 8: in “Do Waiting Threads Receive
> Alerts and APCs” the same parameters for the table give YES! Do we have
> a
> another contradiction!
>
> Sincerely;
> Mike Jones
>
> “Jake Oshins” wrote in message
> news:xxxxx@ntdev…
>> I recommend reading the paper about locks and synchronization at
>> http://www.microsoft.com/whdc/driver/kernel/default.mspx. There are also
> a
>> bunch of other useful papers there that might help.
>>
>> –
>> Jake Oshins
>> Windows Kernel Group
>>
>> This posting is provided “AS IS” with no warranties, and confers no
> rights.
>>
>>
(1) I thought Terminate wait would be the same thing as Wait Aborted? Hence
the tables are wrong.
(2) If indeed that is the case then the tables are wrong and indeed for your
problem it should say Alertable set to TRUE.
I am confused too
Sincerely
Mike Jones
“antonis” wrote in message news:xxxxx@ntdev…
> Mike,
>
> As far as I can see the tables are identical in the paper and in the ddk
> (except for the alerts column that is missing in the paper). But if we are
> talking about
> ambiguity check this: Table 8. shows that when waiting with
Alertable=False
> WaitMode=UserMode, a usermode APC cannot terminate the wait. But the same
> paper a couple of paragraphs down says:
> " If a driver calls KeWaitForSingleObject or KeWaitForMultipleObjects with
> WaitMode set to UserMode, but Alertable set to FALSE, the wait will abort
> with STATUS_USER_APC if the thread is being terminated…"
> So will the wait abort in that case or not? Applying some common sense
would
> lead me to believe that the wait will be aborted. But I cannot be sure,
can
> I?
>
> Anyway I don’t mean to criticize the info published in whdc. I am actually
> greatful for its existance, honest.
>
> I would just like to have a clear picture of this APC/alert delivery stuff
> so that I would not have to check that table(which by the way I am not
sure
> if it is correct) everytime.
>
> Thanks,
> Antonis
>
> “Michael Jones” wrote in message
> news:xxxxx@ntdev…
> > Also in the paper Jake Oshins recommends you look at the table 8: You
see
> > that for User-mode APC Terminate is NO when Alertable = TRUE and
WaitMode
> > =
> > KernelMode. Now look at the DDK table 8: in “Do Waiting Threads
Receive
> > Alerts and APCs” the same parameters for the table give YES! Do we
have
> > a
> > another contradiction!
> >
> > Sincerely;
> > Mike Jones
> >
> > “Jake Oshins” wrote in message
> > news:xxxxx@ntdev…
> >> I recommend reading the paper about locks and synchronization at
> >> http://www.microsoft.com/whdc/driver/kernel/default.mspx. There are
also
> > a
> >> bunch of other useful papers there that might help.
> >>
> >> –
> >> Jake Oshins
> >> Windows Kernel Group
> >>
> >> This posting is provided “AS IS” with no warranties, and confers no
> > rights.
> >>
> >>
>
>
>
> (1) I thought Terminate wait would be the same thing as Wait Aborted?
Hence
the tables are wrong.
I believe “Terminate wait” and “Wait Aborted” are used to indicate the same
thing, which is: that the wait call will “unblock” and execution of the
thread will continue.
(2) If indeed that is the case then the tables are wrong and indeed for
your
problem it should say Alertable set to TRUE.
For the case I described previously to be correct it should say NO (as it
already does) an just “copy-paste” the comment “with exceptions, EX. ^C to
terminate)” from the adjacent cell.
Anyway my questions is different, if someone else is trying to follow this
please check the questions in the original post.
Thanks,
Antonis
“Michael Jones” wrote in message
news:xxxxx@ntdev…
> (1) I thought Terminate wait would be the same thing as Wait Aborted?
> Hence
> the tables are wrong.
> (2) If indeed that is the case then the tables are wrong and indeed for
> your
> problem it should say Alertable set to TRUE.
>
> I am confused too
>
> Sincerely
> Mike Jones
>
> “antonis” wrote in message news:xxxxx@ntdev…
>> Mike,
>>
>> As far as I can see the tables are identical in the paper and in the ddk
>> (except for the alerts column that is missing in the paper). But if we
>> are
>> talking about
>> ambiguity check this: Table 8. shows that when waiting with
> Alertable=False
>> WaitMode=UserMode, a usermode APC cannot terminate the wait. But the same
>> paper a couple of paragraphs down says:
>> " If a driver calls KeWaitForSingleObject or KeWaitForMultipleObjects
>> with
>> WaitMode set to UserMode, but Alertable set to FALSE, the wait will abort
>> with STATUS_USER_APC if the thread is being terminated…"
>> So will the wait abort in that case or not? Applying some common sense
> would
>> lead me to believe that the wait will be aborted. But I cannot be sure,
> can
>> I?
>>
>> Anyway I don’t mean to criticize the info published in whdc. I am
>> actually
>> greatful for its existance, honest.
>>
>> I would just like to have a clear picture of this APC/alert delivery
>> stuff
>> so that I would not have to check that table(which by the way I am not
> sure
>> if it is correct) everytime.
>>
>> Thanks,
>> Antonis
>>
>> “Michael Jones” wrote in message
>> news:xxxxx@ntdev…
>> > Also in the paper Jake Oshins recommends you look at the table 8: You
> see
>> > that for User-mode APC Terminate is NO when Alertable = TRUE and
> WaitMode
>> > =
>> > KernelMode. Now look at the DDK table 8: in “Do Waiting Threads
> Receive
>> > Alerts and APCs” the same parameters for the table give YES! Do we
> have
>> > a
>> > another contradiction!
>> >
>> > Sincerely;
>> > Mike Jones
>> >
>> > “Jake Oshins” wrote in message
>> > news:xxxxx@ntdev…
>> >> I recommend reading the paper about locks and synchronization at
>> >> http://www.microsoft.com/whdc/driver/kernel/default.mspx. There are
> also
>> > a
>> >> bunch of other useful papers there that might help.
>> >>
>> >> –
>> >> Jake Oshins
>> >> Windows Kernel Group
>> >>
>> >> This posting is provided “AS IS” with no warranties, and confers no
>> > rights.
>> >>
>> >>
>>
>>
>>
>
>
>
You are correct Antonis. I was looking at the Alerts column. Please accept
my apology.
Sincerely;
Mike Jones
“antonis” wrote in message news:xxxxx@ntdev…
> > (1) I thought Terminate wait would be the same thing as Wait Aborted?
> > Hence
> > the tables are wrong.
>
> I believe “Terminate wait” and “Wait Aborted” are used to indicate the
same
> thing, which is: that the wait call will “unblock” and execution of the
> thread will continue.
>
> > (2) If indeed that is the case then the tables are wrong and indeed for
> > your
> > problem it should say Alertable set to TRUE.
>
> For the case I described previously to be correct it should say NO (as it
> already does) an just “copy-paste” the comment “with exceptions, EX. ^C to
> terminate)” from the adjacent cell.
>
> Anyway my questions is different, if someone else is trying to follow this
> please check the questions in the original post.
>
> Thanks,
> Antonis
>
> “Michael Jones” wrote in message
> news:xxxxx@ntdev…
> > (1) I thought Terminate wait would be the same thing as Wait Aborted?
> > Hence
> > the tables are wrong.
> > (2) If indeed that is the case then the tables are wrong and indeed for
> > your
> > problem it should say Alertable set to TRUE.
> >
> > I am confused too
> >
> > Sincerely
> > Mike Jones
> >
> > “antonis” wrote in message news:xxxxx@ntdev…
> >> Mike,
> >>
> >> As far as I can see the tables are identical in the paper and in the
ddk
> >> (except for the alerts column that is missing in the paper). But if we
> >> are
> >> talking about
> >> ambiguity check this: Table 8. shows that when waiting with
> > Alertable=False
> >> WaitMode=UserMode, a usermode APC cannot terminate the wait. But the
same
> >> paper a couple of paragraphs down says:
> >> " If a driver calls KeWaitForSingleObject or KeWaitForMultipleObjects
> >> with
> >> WaitMode set to UserMode, but Alertable set to FALSE, the wait will
abort
> >> with STATUS_USER_APC if the thread is being terminated…"
> >> So will the wait abort in that case or not? Applying some common sense
> > would
> >> lead me to believe that the wait will be aborted. But I cannot be sure,
> > can
> >> I?
> >>
> >> Anyway I don’t mean to criticize the info published in whdc. I am
> >> actually
> >> greatful for its existance, honest.
> >>
> >> I would just like to have a clear picture of this APC/alert delivery
> >> stuff
> >> so that I would not have to check that table(which by the way I am not
> > sure
> >> if it is correct) everytime.
> >>
> >> Thanks,
> >> Antonis
> >>
> >> “Michael Jones” wrote in message
> >> news:xxxxx@ntdev…
> >> > Also in the paper Jake Oshins recommends you look at the table 8: You
> > see
> >> > that for User-mode APC Terminate is NO when Alertable = TRUE and
> > WaitMode
> >> > =
> >> > KernelMode. Now look at the DDK table 8: in “Do Waiting Threads
> > Receive
> >> > Alerts and APCs” the same parameters for the table give YES! Do we
> > have
> >> > a
> >> > another contradiction!
> >> >
> >> > Sincerely;
> >> > Mike Jones
> >> >
> >> > “Jake Oshins” wrote in message
> >> > news:xxxxx@ntdev…
> >> >> I recommend reading the paper about locks and synchronization at
> >> >> http://www.microsoft.com/whdc/driver/kernel/default.mspx. There are
> > also
> >> > a
> >> >> bunch of other useful papers there that might help.
> >> >>
> >> >> –
> >> >> Jake Oshins
> >> >> Windows Kernel Group
> >> >>
> >> >> This posting is provided “AS IS” with no warranties, and confers no
> >> > rights.
> >> >>
> >> >>
> >>
> >>
> >>
> >
> >
> >
>
>
>