ntdll: make NtDelayExecution a bit more efficient

[Francois Gouget]

On Fri, 8 Mar 2013, Juan Lang wrote:
[...]
> > Michael Stefaniuc wrote:
> > >> i.e. commit 8099c2b9. JW says "... to more closely resemble Windows
> > >> behavior.  The key is to yield in a Sleep..."

I think it's really a three patch series and the first one has the 
clearer commit message:

commit 08c0f691cebc0994bb94bc160c080cccf8068561
Author: Jeremy White <jwhite at codeweavers.com>
Date:   Sat Oct 9 02:26:29 2004 +0000

    Made NtDelayExecution with a 0 timeout yield the CPU, as it is
    supposed to.

commit de91a8dd0fd01da20656a4f6be423e5ae2df785f
Author: Alexandre Julliard <julliard at winehq.org>
Date:   Mon Oct 11 20:11:01 2004 +0000

    Implemented NtYieldExecution.

commit 8099c2b9fd5b80f35868936a6e96f732106c3286
Author: Jeremy White <jwhite at codeweavers.com>
Date:   Tue Nov 2 19:32:03 2004 +0000

    Tune the behavior of Sleep() and Waitxxx() to more closely resemble
    Windows behavior.  The key is to yield in a Sleep and in any Wait that
    times out.


> > If the ancient wisdom isn't backed by tests there's a fair chance that
> > > it might not be applicable today. Or that it was a wrong theory
[...]
> I no longer recall which app it was Jeremy was working on fixing, but there
> was at least one app that depended on this behavior. See Jeremy's posts on
> "RFC: yield on Waits" and "Threading issues".

http://www.winehq.org/pipermail/wine-devel/2004-November/030796.html


I suspect it was the Shockwave Director plugin(*). If I remember 
correctly it had a thread in a tight loop just calling PeekMessage() and 
Sleep(0) or some such. Then it had another thread that was doing the 
real work. But because the first thread was not yielding the second's 
performance suffered (even more so as the processors of the time where 
mostly single core).


(*) Nothing to do with Shockwave Flash, aka Macromedia Flash aka Adobe 
Flash.

-- 
Francois Gouget <fgouget at codeweavers.com>