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

TalkBack 34 of 116:

Next »

« Previous

• Thread View
• Flat View

hmmm . . ..

"A thread is a thread. There's no guarantee that The two or four threads from my software will get run at the same time on different cores."

Yes and no. They can set their affinity, but I think that's more a suggestion and not a guarantee.

"But why should multi threaded software be sharing time with system operations that most people don't even no exsist or low cpu intensive tasks. Vista can run on one core fine, single thread programs can share it ie the firefoxes the word ect."

Why not? AFAIK, there's no reason to treat any process as being any more important than the others.

Besides, having single threaded programs share a single core pretty much negates the reason for having multiple cores anyways - you want these programs to act as independently as possible, so if one manages to take up a lot of CPU on one core the others remain responsive because they are on other cores.

The idea is that even if you're not running any multithreaded applications, you can still take advantage of multiple cores for multiple single threaded applications.

"And finally the task of writing a multithreaded program in which the threads share the program workload equally is very difficult."

Agreed, especially in C++ which was never designed for concurrent programming in the first place. Java and C# are a bit better, and F# looks very promising for developers.

This is one area where the language can make a difference, because some languages already have the constructs for creating threaded applications, while others don't.

"There is no guarantee on how windows is going to prioritize and run your threads."

And frankly there never will be. OSes have been steadily moving away from guaranteeing things.

You're just going to have to code like everybody else - assume that nothing is guaranteed, and design the threads to be as independent as possible and try hard not share any resources.

If your threads are sharing a lot of resources, then perhaps you should rethink your reasons for making them separate threads in the first place.

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

• Building the Virtualized Enterprise with VMware Iinfrastructure VMware VMware virtualization software has been adopted by over 120,000 enterprise ... Download Now
• The True Costs of Virtual Server Solutions VMware In an economic environment that is repeatedly heralding the message "do ... Download Now
• Unrivaled support from Novell, now available for Red Hat Novell If Linux is going to power your mission-critical applications, you'd ... Download Now