In article ,
Joe Seigh writes:
|
| I'm not sure that the gui by itself is enough to justify a multi-core
| cpu. And there are problems enough in multi-threaded gui, even apart
| from deadlocks caused by inexperienced programmer mixing threads and OO
| callbacks. Consider mouse events queued before but received after a
| resize operation. The mouse coordinates are in the wrong frame of reference
| and all wrong. Gui designers design as if the event queue was = 1 at all
| times.

Take a mouse event in an unrealistically simple design. This is picked
up by the kernel, and passed to the display manager, which converts it
into another form and passes it to the application. That does something
with it, passes a message to the display manager, which calls the kernel
to update the screen. The user does not see any effect until that has
completed.

At best, you have 4 context switches, 2 of which are between user-level
contexts, and it is common for there to be MANY more. Now, consider
that being done as part of drag-and-drop - you want the process to
happen in under 2 milliseconds (certainly under 5), or it will start to
be visible. That can be 1,000+ context switches a second, and some
of those contexts have large working sets, so you are reloading a
lot of cache and TLBs.

One of the advantages of a multi-core system is that you don't need to
switch context just to pass a message if the threads or processes are
on different cores. You just pass the message.


Regards,
Nick Maclaren.