wait until the interrupt fires. :)
Eugene
From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Tuesday, February 12, 2013 2:58 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] WaitForEvent Idle Race Condition
Especially since WaitForEvent can only be called at TPL_APPLICATION. Pretty
Especially since WaitForEvent can only be called at TPL_APPLICATION. Pretty
hard to use in an I/O driver.
Tim
From: Andrew Fish [mailto:af...@apple.com]
Sent: Tuesday, February 12, 2013 1:54 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] WaitForEvent Idle Race Condition
On Feb 12
>
>
> From: Andrew Fish [mailto:af...@apple.com]
> Sent: Tuesday, February 12, 2013 1:37 PM
> To: edk2-devel@lists.sourceforge.net
> Subject: Re: [edk2] WaitForEvent Idle Race Condition
>
> Eugene,
>
> I think this is the way it works. CoreCheckEvent() and Cor
paths (at least for those protocols that make use of events).
Eugene
From: Andrew Fish [mailto:af...@apple.com]
Sent: Tuesday, February 12, 2013 1:37 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] WaitForEvent Idle Race Condition
Eugene,
I think this is the way it works. CoreCheck
Eugene,
I think this is the way it works. CoreCheckEvent() and CoreSignalEven() both
have locks that raise to TPL_HIGH_LEVEL. But we never signal (call an events
Notify Function) an event at TPL_HIGH_LEVEL.
What if NumberOfEvents > 1 and the 1st event is checked, and then a timer tick
happen
It appears that there is a race condition in WaitForEvent... after all events
are checked the idle event is signaled. But if a timer tick interrupt comes in
and schedules work (SignalEvent) after the loop is done but before the event is
signaled, we will delay unnecessarily for an additional ti
