[interfacekit] Re: Proposal: Only one thread per application(not windo= = w) on app_server side without polling

On Sun, 27 Jul 2003 17:09:19 +0200 Massimiliano Origgi <
origgi@xxxxxxxxxxxx> wrote:
> >On Sat, 26 Jul 2003 18:57:43 +0200 Massimiliano Origgi <
> >origgi@xxxxxxxxxxxx> wrote:
> >> Well, that's a nice idea and speaking of CPUs as you mentioned, 
> > > the 
> >> limit 
> >> could be set to the number of CPUs available as more threads 
> > > wouldn't 
> >> do any 
> >> good anyway.
> 
> >That's simply not true. Applying this argument on a one CPU machine, 
> >one thread per application would be sufficient, too. But BeOS 
> > proves, 
> >that pervasive use of threads significantly improves the UI 
> >responsiveness.
> 
> I'm not making the app_server single threaded, the responsiveness 
> comes from 
> the high priority threads which handle things like the mouse pointer,

Although it's certainly important to have a small latency for sending 
mouse/keyboard events after their occurence, this doesn't necessarily 
make the applications' feedback to it faster, since this is mainly 
based on how quick the app server and the application can react one 
this event. E.g. if you have multiplexing of several windows to one app 
server thread, a window getting the event might not be able to have 
something drawn by the app server quickly, because the responsible 
thread might just be busy with something else. If the task in progress 
takes a long time, the reaction to the foremention event will be 
postponed for a long time. Even funnier, if the thread doesn't even do 
actual work, because it blocks on a semaphore; then the CPU is 
available, but the work to be done isn't done nevertheless.

> but 
> having 2 threads with the same priority(aka 2 windows) fight for 
> system 
> resources doesn't give better performance as it causes more context 
> switches. 

If you mean by performance system throughput, then this may or may not 
be true -- the above example (a thread blocking on a semaphore, while 
it also has other work to do, that could be done at the same time) does 
at least indicate that it can't be said in general -- but my concern 
was responsiveness anyway.

With a multiple threads approach -- thus letting the system do the 
scheduling -- you get a much fairer scheduling of the work to be done. 
This might not result in a lower average responsiveness, but will avoid 
unaesthetic peaks. BTW, adding a new thread per window will even 
increase the overall percentage of CPU time the app server is getting 
in busy situations.

CU, Ingo

Other related posts: