I think some of you have never debugged the network stack or enabled PnP
spew during boot. Spurious,indeed!
WD
On Oct 8, 2009 4:48 PM, "Jose Catena" wrote:
> Logging operations take a short amount of time and are spurious, in > this
case, a worker thread...
If a task is to be repeated, I think
> Logging operations take a short amount of time and are spurious, in
> this case, a worker thread would work better, it seems.
If a task is to be repeated, I think it is better a system task: while it is
waiting for an event it does not consume any cpu, and wake-up upon event and
back to wait i
> You (the code) is spinning non-atomically on a spinlock at passive
> then raising the irql to dispatch to "acquire" it. This makes no sense
> whatsoever. Another code can race you to this place.
>
> Why not just use a normal spinlock?
I can guess why such a construct is used, but better let Alek
On 8-Oct-09, at 9:32 AM, Dmitry Gorbachev wrote:
> Hi,
>
>> This code has multiple synchronization issues, such as spinning on a
>> test-for-spin-lock, which is non-atomic... might as well get rid of
>> the spinlock.
>
> That synchronization code is borrowed from KdpSerialDebugPrint. Please
> tel
Hi,
> This code has multiple synchronization issues, such as spinning on a
> test-for-spin-lock, which is non-atomic... might as well get rid of
> the spinlock.
That synchronization code is borrowed from KdpSerialDebugPrint. Please
tell what are issues, I will fix then in both places.
> Also, yo
Why are you using this bad/broken API?
Why are you doing an exchange without even checking the result?
Just use InterlockedAdd (but you're not accessing KdpFreeBytes safely
elsewhere, so again, you're just wasting time doing bad
synchronziation).
Best regards,
Alex Ionescu
On Wed, Oct 7, 2009
