Problem with XP scheduler?
in [Win32 Kernel]
|
From: J de Boyne Pollard on 30 Dec 2009 09:53 DB> My real complaint with this whole discussion is that DB> multitasking means different things to different people. DB> If you are an old timer like me, there were major DB> screams 30 years ago when Unix claimed to be DB> multitasking. At that time most companies described DB> what we now consider as multitasking as DB> multiprocessing and that tasks were what we currently DB> call threads. And 30 years ago, Unix did not support DB> threads. Yes (although with either definition the trolling here is false). More fundamentally, "task" means different things to different people. In some cases, a "task" is what in the Windows NT model would be a "thread". In other cases, a "task" would be a Windows NT "process". In yet other cases still, a "task" is what in the Solaris model would be a "light weight process". Teminology is and long has been, most definitely, an issue in this area. If one has clear definitions of "thread", "process", and "processor", then "multi- thread", "multi-process", and "multi-processor" have clear meanings. But since "task" is often ambiguous, "multi-tasking" is as well. Let's not get started on the difference between "concurrent" and "multi-programmed" or what "job" means ... (-:
From: Anne & Lynn Wheeler on 30 Dec 2009 11:35 J de Boyne Pollard <J.deBoynePollard(a)Tesco.NET> writes: > Yes (although with either definition the trolling here is false). > More fundamentally, "task" means different things to different > people. In some cases, a "task" is what in the Windows NT model would > be a "thread". In other cases, a "task" would be a Windows NT > "process". In yet other cases still, a "task" is what in the Solaris > model would be a "light weight process". Teminology is and long has > been, most definitely, an issue in this area. If one has clear > definitions of "thread", "process", and "processor", then "multi- > thread", "multi-process", and "multi-processor" have clear meanings. > But since "task" is often ambiguous, "multi-tasking" is as well. > Let's not get started on the difference between "concurrent" and > "multi-programmed" or what "job" means ... (-: multiprogramming was mainframe ... more lightweight "threads" within the same address space. multi-tasking could be more heavy weight .... and could involve different address spaces. multiprocessing tended to be multiple real processors. there was "tightly-coupled" (shared-memory) multiple processors .... there was also "loosely-coupled" (non-shared-memory) but possibly shared disk or other i/o, multiple processors (clusters) ... and then there are the "shared-nothing" clusters. in the 90s ... sequent claimed that it did much of the "windows" scaleup work for shared-memory multiple processors (getting NT running efficiently on more than two-processor multiple processor machines. when charlie was working on fine-grain multiprocessor locking for cp67 kernel (late 60s), he invented compare&swap instruction (name of instruction chosen because CAS are his initials). The attempt to get it included in 370 (mainframe) multiprocessor was initially rebuffed .... claiming that TEST&SET instruction was more than sufficient. The challenge was to come up with uses for compare&swap instruction that weren't multiprocessor specific. Thus was born the examples of using compare&swap in multithreaded/multiprogrammed applications ... to coordinate the different threads ... regardless of whether the underlying hardware was just a single processor or multiple processors. It became standard use for highly optimized, multithreaded subsystems .... like various kinds of database management systems (DBMS) ... and started showing up on processors other than 370s. description from current mainframe principles of operation (much of it the original justification used for compare&swap in early 70s): A.6 Multiprogramming and Multiprocessing Examples http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dz9zr003/A.6?DT=20040504121320 scheduling can be somewhat orthogonal ... I had done dynamic adaptive resource management for cp67 as undergraduate in the 60s (sometimes referred to as the "fair share scheduler" because default resource management policy was "fair share". -- 40+yrs virtualization experience (since Jan68), online at home since Mar1970
From: Alexander Grigoriev on 30 Dec 2009 11:39 I suggest you learn how multithreading with priorities work. And all modern non-realtime dispatchers (Windows, Linux, etc) will happily preempt ("take the CPU time from other threads" in your words) a thread when higher priority thread is woken up. "tanix" <tanix(a)mongo.net> wrote in message news:hhellm$k12$6(a)news.eternal-september.org... > In article <#cJ1l6LiKHA.1460(a)TK2MSFTNGP06.phx.gbl>, "Alexander Grigoriev" > <alegr(a)earthlink.net> wrote: > > First of all, why do you top post? > Do you know what top posting means? > >>I think you'll agree that Windows scheduler could do better job for taming >>runaway threads. It's pretty easy to detect such threads - if a thread >>uses >>up its timeslice repeatedly, > > Thread should NEVER be able to take the CPU time from other threads. > ALL it has is its own time slice. > Period. > >> it's running away. For such a thread, the >>scheduler should apply penalty. > > First of all, the thread should not be allowed to run > for a longer time than its alloted timeslice. >
From: Anne & Lynn Wheeler on 30 Dec 2009 11:57 re: http://www.garlic.com/~lynn/2009s.html#54 Problem with XP scheduler? actually, in the mid to late 80s (>20 years ago) looking at some of the unix scheduler code ... I realized that I had rewritten it nearly two decades previously (over 40 yrs ago) in cp67. I attribute it to possibly have originated in CTSS. Some of the CTSS people went to science center on the 4th flr ... and did (virtual machine) cp40 ... which then morphed into (virtual machine) cp67. Other of the CTSS people went to Multics on the 5th flr ... and there is various folklore regarding Multics and UNIX. In any case, when some people from the science center came out and installed cp67 at the univ in Jan68 ... I got to do lots of changes/enhancements. One was rewritting the scheduling infrastructure .... part of that original cp67 scheduling implementation (that I rewrote) bore some amount of similarity to the unix scheduling implementation that I later ran across in the mid & late 80s. misc. past posts mentioning fair share scheduler http://www.garlic.com/~lynn/subtopic.html#fairshare that have been comments in the past about multi-core being a solution for poorly implemented schedulers ... as long as there are at least as many different core/processors as there are things to run ... then a scheduler is never faced with decision about what *NOT* to run (at any particular moment) ... sort of the inverse of scheduling decision about what to run ... as long as there are enough processors to run everything. -- 40+yrs virtualization experience (since Jan68), online at home since Mar1970
From: tanix on 30 Dec 2009 13:26
In article <eCUSLyTiKHA.3792(a)TK2MSFTNGP02.phx.gbl>, "Boba" <Boba(a)somewhere.net> wrote: >"tanix" <tanix(a)mongo.net> wrote in message >news:hhemg5$k12$9(a)news.eternal-september.org... >> ... >> So, you may delete files, move the entire directories around, >> or ALL sorts of "magic". > >been there, seen that... had data lost ;( > >> And what does THAT tell you? > >THAT should also tell you not to use winblows for >that type of business. Not good enough. It is just a fact of reality. Windows is what is there. You can not just scrap it. But instead of inventing all these new bells and whistles, they should have paid more attention to the bugs that exist in windows from day one, and this is just one of them. And it is not merely some bug, but a fundamental problem. These desktop updates are just an ugly hack and it is a pitty it is not taken care of by now. I do not recall seeing something like that on Linux. -- 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, organized by major topics of language, tools, methods, techniques. |