Problem with XP scheduler?
in [Win32 Kernel]
|
From: Pavel A. on 31 Dec 2009 21:17 http://pavel_a.fastmail.fm/koshki/troll.jpg TIA! --pa
From: Anne & Lynn Wheeler on 1 Jan 2010 10:24 Peter Flass <Peter_Flass(a)Yahoo.com> writes: > According to Pascal Zachary, and some memos on Bitsavers, it appears > Cutler & Co. were working on a new OS for a new system (Prism/Mica) at > DECWRL. When DEC, or should I say Digital, canceled that Cutler was > happy to move to M$, where he could still develop a brand-new OS from > scratch. re: http://www.garlic.com/~lynn/2009s.html#54 Problem with XP scheduler? http://www.garlic.com/~lynn/2009s.html#55 Problem with XP scheduler? http://www.garlic.com/~lynn/2009s.html#59 Problem with XP scheduler? http://www.garlic.com/~lynn/2009s.html#62 Problem with XP scheduler? thnks, comments I had seen were DEC (former VMS) people going to m'soft to do NT ... and lots of DEC technology possibly being part of NT. The main point was that people didn't have long SMP history contributing to decision involving sequent in NT SMP scaleup. This isn't exactly the same as straight performance (i.e. NT having equivalent thruput to UNIXes of the period on the same hardware) ... but is likely work on finer-grain locks in the kernel ... so adding processors showed some incremental thruput (and weren't spending all their time waiting/spinning on locks). Some of the (other) performance issues was implied in the comments about weeks away from having to explain to their CEO that a high-end UNIX would be used for some deployment (rather than NT) ... until the responsible executive changed the definition of the deployment to be only that which NT could do. when charlie was doing work on cp67 fine-grain locking and invented the compare&swap instruction ... one of the scenarios was showing compare&swap directly updating variables ... as opposed to (barrier) locks around the updating of the variables (scenario for various kinds of applications like database management systems ... for multithreaded work ... whether running in a multiprocessor environment or not). misc. past posts mentioning smp &/or compare&swap instruction http://www.garlic.com/~lynn/subtopic.html#smp The recent Larrabee thread in comp.arch has touched on wide variety of topics ... but yesterday there were couple posts discussing compare&swap variations. misc. past posts in the Larrabee thread: http://www.garlic.com/~lynn/2009s.html#18 Larrabee delayed: anyone know what's happening? http://www.garlic.com/~lynn/2009s.html#20 Larrabee delayed: anyone know what's happening? http://www.garlic.com/~lynn/2009s.html#22 Larrabee delayed: anyone know what's happening? http://www.garlic.com/~lynn/2009s.html#23 Larrabee delayed: anyone know what's happening? http://www.garlic.com/~lynn/2009s.html#29 channels, was Larrabee delayed: anyone know what's happening? http://www.garlic.com/~lynn/2009s.html#30 Larrabee delayed: anyone know what's happening? http://www.garlic.com/~lynn/2009s.html#31 Larrabee delayed: anyone know what's happening? http://www.garlic.com/~lynn/2009s.html#32 Larrabee delayed: anyone know what's happening? http://www.garlic.com/~lynn/2009s.html#33 Larrabee delayed: anyone know what's happening? http://www.garlic.com/~lynn/2009s.html#34 Larrabee delayed: anyone know what's happening? http://www.garlic.com/~lynn/2009s.html#35 Larrabee delayed: anyone know what's happening? http://www.garlic.com/~lynn/2009s.html#36 Larrabee delayed: anyone know what's happening? http://www.garlic.com/~lynn/2009s.html#42 Larrabee delayed: anyone know what's happening? http://www.garlic.com/~lynn/2009s.html#43 Larrabee delayed: anyone know what's happening? http://www.garlic.com/~lynn/2009s.html#48 Larrabee delayed: anyone know what's happening? .... couple weeks and it has been 42yrs since I first got to play with cp67 -- 40+yrs virtualization experience (since Jan68), online at home since Mar1970
From: Tim Roberts on 3 Jan 2010 19:06 tanix(a)mongo.net (tanix) wrote: > >It looks totally synchronous with the mouse and keyboard events. > >From statistical standpoint, the chance is probably > 90% that a >task switch will occure at exactly the same time when you click >on something. False. Remember that user interfaces are interminably slow compared to the processor. Even for a lightning fast typist, there will be 3 to 5 task switches between keystrokes, and there will even multiple task switches between "mouse down" and "mouse up". >It is like task switching is some kind of a synchronous event >that only happens when you service the mouse click or keyboard >events. Well, depending on the type of mouse and keyboards, those events will cause an interrupt, which can trigger a re-evaluation of the task priorities. >What happens as a result, and especially if your box is uder a >heavy load, is that when you click on something, what you think >you clicked on is not actually what happened as far as windows >interpreted it. But what happened is that other event from a >different tast got processed. As a result things get totally >screwed up in terms of them happening according to your >expectation. > >Anybody knows the scoop on this one? Yes, the scoop is that you don't understand Windows. Task switching and mouse/keyboard focus are not related. It doesn't matter how many task switches occur in the meantime, mouse and keyboard events will be delivered to the thread that has the focus. -- Tim Roberts, timr(a)probo.com Providenza & Boekelheide, Inc.
From: David Craig on 3 Jan 2010 20:28 Can we confuse him with some irreverent details? For instance when a key is struck or a mouse event occurs, whatever thread is currently running from which ever process owns that thread will be 'tasked' to handle the interrupt. The 'event' will then be sent to usually the Win32 subsystem for eventual delivery to the thread & process that owns the input focus. Since he seems so insistent upon keeping his misconceptions about Windows, we might not want to keep it too simple. "Tim Roberts" <timr(a)probo.com> wrote in message news:50c2k5d3uhi6qc3fkq71qaee77upt6q7ph(a)4ax.com... > tanix(a)mongo.net (tanix) wrote: >> >>It looks totally synchronous with the mouse and keyboard events. >> >>From statistical standpoint, the chance is probably > 90% that a >>task switch will occure at exactly the same time when you click >>on something. > > False. > > Remember that user interfaces are interminably slow compared to the > processor. Even for a lightning fast typist, there will be 3 to 5 task > switches between keystrokes, and there will even multiple task switches > between "mouse down" and "mouse up". > >>It is like task switching is some kind of a synchronous event >>that only happens when you service the mouse click or keyboard >>events. > > Well, depending on the type of mouse and keyboards, those events will > cause > an interrupt, which can trigger a re-evaluation of the task priorities. > >>What happens as a result, and especially if your box is uder a >>heavy load, is that when you click on something, what you think >>you clicked on is not actually what happened as far as windows >>interpreted it. But what happened is that other event from a >>different tast got processed. As a result things get totally >>screwed up in terms of them happening according to your >>expectation. >> >>Anybody knows the scoop on this one? > > Yes, the scoop is that you don't understand Windows. Task switching and > mouse/keyboard focus are not related. It doesn't matter how many task > switches occur in the meantime, mouse and keyboard events will be > delivered > to the thread that has the focus. > -- > Tim Roberts, timr(a)probo.com > Providenza & Boekelheide, Inc.
From: tanix on 4 Jan 2010 02:31
In article <50c2k5d3uhi6qc3fkq71qaee77upt6q7ph(a)4ax.com>, Tim Roberts <timr(a)probo.com> wrote: >tanix(a)mongo.net (tanix) wrote: >> >>It looks totally synchronous with the mouse and keyboard events. >> >>From statistical standpoint, the chance is probably > 90% that a >>task switch will occure at exactly the same time when you click >>on something. > >False. > >Remember that user interfaces are interminably slow compared to the >processor. Even for a lightning fast typist, there will be 3 to 5 task >switches between keystrokes, and there will even multiple task switches >between "mouse down" and "mouse up". I hope you know what you are talking about. Because I do. >>It is like task switching is some kind of a synchronous event >>that only happens when you service the mouse click or keyboard >>events. > >Well, depending on the type of mouse and keyboards, those events will cause >an interrupt, which can trigger a re-evaluation of the task priorities. Yep. That is probably what is going on. The objection I have that any evaluation should not be done in SYNCHRONOUS manner. Because the task swith may drastically affect what user experiences. Once you click on something, you expect that something to get active. But what happens, is something totally different gets your mouse/keyboard event. Seems to me a serious problem with architecture/design. >>What happens as a result, and especially if your box is uder a >>heavy load, is that when you click on something, what you think >>you clicked on is not actually what happened as far as windows >>interpreted it. But what happened is that other event from a >>different tast got processed. As a result things get totally >>screwed up in terms of them happening according to your >>expectation. >> >>Anybody knows the scoop on this one? >Yes, the scoop is that you don't understand Windows. What? :--} Get lost, donkey. Enough. > Task switching and >mouse/keyboard focus are not related. It doesn't matter how many task >switches occur in the meantime, mouse and keyboard events will be delivered >to the thread that has the focus. -- Programmer's Goldmine collections: http://preciseinfo.org Tens of thousands of code examples and expert discussions on C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript, PHP, organized by major topics of language, tools, methods, techniques. |