Microsoft Predictions for 2008: Games group housecleaning continues (Microsoft in 2008: 10 Predictions)

TalkBack 32 of 116:

Next »

« Previous

• Thread View
• Flat View

It's a bit more complex than that . . .

"What hes saying is software doesn't ask the cpu to run an operation. It tells the os hey, I need this done, the os does it, and then gets back to software. There is a layer between the hardware and the software called the os or Operating system."

Well, there are two extremes, and Windows is somewhere in the middle.

DOS was one extreme, and software usually ran nearly 100% on the CPU with the OS doing almost nothing (other than a few simplistic mouse and video things)

Emulators are the other extreme, with every instruction being run by the emulator and the program has no access to the CPU at all (even though it is fooled into thinking so).

Windows is somewhere in the middle. If you're doing something like a math operation or a for loop, then as long as you don't exceed your time slice you're allowed to do the computations pretty much directly.

On the other hand, the user interface and I/O stuff is passed off to the OS and it handles them.

So Windows is sorta a hybrid of the two, but as processors become more powerful, it's moving towards being a virtualizer.

"Straighter to the point, yes software developers have to write code designed to be processed in parallel, "aka parallel processing", but the os has to be able to handle such a request. Currently both vista and xp takes a process assigns the least taxed core to its requests, and thats the end of it. There is no functionally for the software to tell the os, 'hey you can do both of these things at the same time if you want'."

Actually, there is: They're called threads. A developer can say "I want to do this set of operations in one thread, and that set of operations in another." The OS can then take each thread and place it in a different processor/core.

"I am unaware of any way to compile a single program in an x86 environment in such a way to accomplish this task."

Multiprocessing has nothing to do with compiling - it has to do with designing the program to be multithreaded.

"Currently both vista and xp takes a process assigns the least taxed core to its requests, and thats the end of it."

Hardly. Even before computers had multiple cores, they've been able to do many tasks at once on a single core.

DOS was what you're imagining: A process starts, everything goes into the background, and nothing else happens until the process finishes. This model has been dead for years.

Windows 3 allowed the ability to switch between several processes, and each process could hand control over to the OS, which would then pass control to the next program. The OS divided time into "slices" and tried to keep the distribution of the time spent by each program fairly equal. However, the OS was sill at the mercy of the program if the program didn't give up control of the CPU.

Windows 95 made the process switching mandatory - if a process didn't hand over control before the time slice was over, the OS forcibly yanked control from the process and handed it to the next program. There is no such thing as a true "background" process (except the OS's time slicer) in this model: A background process is simply one with a smaller time slice.

Of course, this time slicing is done thousands of times a second so you have the impression that they are all running simultaneously.

Now with true multiprocessing, processes can actually run simultaneously in a true parallel fashion - but the time slicing stuff is still in place: Control over the processor the code is running on is still taken away when the time slice is over.

Now enter threads: A thread is similar to a process in that it can have its own time slice and can be placed on a different processor than other threads, but it's owned and managed by a single process, and as such the developer can create a program that uses several processors.

You are right about one thing: Several processes trying to share memory is a problem, and that can cause programs to lockup. Usually it's left to the developer to determine how the program should bes communicate with other programs in a way to avoid deadlocks and race conditions.

Usually when that happens the user has to tell the OS to forcibly shut down the program(s) that are causing problems. The OS itself is largely unaffected by program lockups because the time slicer will eventually force the program to give up control and give control back to the OS.

Posted by: CobraA1   Posted on: 12/19/07 You are currently: a Guest | Members login | Terms of Use

Alert moderator to an offensive message

Subscribe to this discussion via Email or RSS

SponsoredWhite Papers, Webcasts, and Downloads

• Three Steps You Need to Know to Stop Data Loss Varonis Sensitive data exposed to misuse or loss... it is the stuff of nightmares ... Download Now
• The True Costs of Virtual Server Solutions VMware In an economic environment that is repeatedly heralding the message "do ... Download Now
• Why Isn't Server Virtualization Saving Us More? A Few Small Changes May Dramatically Increase Your Efficiency VMware Companies have rapidly adopted server virtualization over the past few ... Download Now