Re: [AD] proposal: al_sleep()

[Elias Pschernig <elias@xxxxxxxxxx>]

On Fri, 2004-01-02 at 15:30, aj wrote:
> > > > Just modifying yield_timeslice (and updating the docs) seems to be the
> > > > most simple thing to do, with no need to introduce a new function.
>
> what about changing the meanings of everything else in the lib while your 
> at it.

Um, it would only change on 2 (well, the 2 main, but still) platforms,
and it makes more sense. Anyway, I'm also happy with the al_sleep(0)
solution proposed by Stepan, where al_sleep(0) does what I want
yield_timeslice() to do.

> >  And by now I still fail to see when the current
> >yield_timeslice in Windows/Linux is useful.
> 
> 
> ok,  lets say i have 2 programs running.
> 
> both use yield_timeslice(),  they both would get 50% CPU each.... but 
> because they use yield_timeslice they get onto the CPU more often, then if 
> they had no yeilding.
> so they get to poll the hardware more often and therefore a more reposnsive.
> 

If they both don't do yield_timeslice(), they get 50% CPU each as well..
If they both call Sleep(1), they also get 50% each (if they need it,
else not, and the idle thread gets the rest, as it should be). With
yield_timeslice, CPU power is simply being wasted.

> 
> now,  imagine we have 2 programs running.
> appA  uses yield_timeslice  and  appB  uses your Sleep(1)
> 
> appA  will get 99% CPU  and  appB will get 1% CPU
> 
> so appA is now extremely more responsive, and your  appB using sleep(1)  is 
> now got  crap response.

Well, the responsiveness of the app using Sleep(1) still should be very
high, since it will get to execute every timeslice. That's as often as
it can get executed. The Sleep(0) case just will always use up it's
complete timeslice - but this doesn't increase responsiveness much. At
least to me there is full respnosiveness if something is called every
timeslice.

So, to me it seems resonable, if an application has responded to an
event after it gets it's timeslice, it should not poll inside the same
timeslice again (with Sleep(0)) - but instead call Sleep(1) and poll
again for an event in the next timeslice.

And with Allegro I'm probably most interested in the case where all the
running applications together take <= 100% - else performance will
suffer in any case.

> 
> i would prefer to have a situation like the 1st example, where both 
> yield,  both get 50% cpu and both are mega responsive.
> 
> this applys to threads of the same app too; because you sleep a thread not 
> an app(process).
> 

Well, Allegro's threads other than the main thread are sleepinn most of
the time already - and are only waked up by events. So they do already
what I'd also like the main thread to do.

-- 
Elias Pschernig <elias@xxxxxxxxxx>