Jump to content
  • Advertisement
Sign in to follow this  
jf_wangfeng

How many threads is suitable?

This topic is 4770 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

If I design a game for a PC with a cpu of 1.0G and a 256MB memory,how many threads are suitable? The threads are used for collision detection. And I want to know whether it is a good way to make a thread(collision detection) for each moving object in the game.

Share this post


Link to post
Share on other sites
Advertisement
On a single CPU machine, having multiple threads only helps (in terms of performance) when the threads are often blocked for I/O. Since collision detection normally involves only calculations, having more than one collision detection thread will not help at all on a single processor architecture, as they will all compete for the same resource (CPU). In fact, having even a single separate thread for collision detection will not help (again in terms of performance) if the main thread is not doing I/O.

Tom

Share this post


Link to post
Share on other sites
It's simpler to write many algorithms if you don't have to worry about them having to explicitly stop so that other code can be run (i.e. you don't have to manually split up you algorithm).

However, the simplification offered in this respect is almost always outweighed by the complexity of sharing data across threads.

Share this post


Link to post
Share on other sites
Multiple threads can be usefull if you are writing a simulation in which each step takes a long time ( >10 ms for example or more).
For example the simulation resolves differential equations, compute collisions,...

In this situation you want to be able to move the scene at a interactively speed.
If you have a single thread there is no solution because you have to wait until the pass has finished; furthermore you are unable to use the GUI interface during this time interval.

The solution is to begin a new thread that moves the simulation while the main thread acquires the input and moves the scene accordingly; or acquire the command to stop the simulation.
I used a solution in which if there is input the simulation thread sleeps until there is no new input so I can compute a complex simulation and move the scene at interactively speed; another solution is give to the sim thread a lower priority.

As you can see a second thread is usefull.

However multithreading is not simple!

You know that two threads should not access the same resource (for example a data structure) simultaneously in I/O.
In fact if a thread modify shared data while the other is reading it the result can be undefined.

In this case the simplest solution is to use a "semaphore"; in practice when you have to modify the data lock it and when you finished unlock it.
If a thread wants to modify the data it must wait until the data is unlocked again (green light).
The semaphore can be implemented in its simplest form in this form


class Semaphore{
public:

Semaphore() { locked = false; }
bool Lock() { return locked ? false : (locked = true); }
void Unlock() { locked = false; }

private:
bool locked;
};

class YourData : public Semaphore{
...
};




and in the thread



while(!data.Lock()); // lock

// it's safe to modify it

data.Unlock(); // unlock





Obviously a thread should not pass with the red light (or it will be a crash); also it should not sabotage the semaphore (calling Unlock if it did not Lock previously ) [smile]

You can google for other solutions (see mutex and/or semaphores). This is the simplest I can find.

In general I suggest you to use only one thread because it is simpler and efficient than having multiple threads; but there are situations that require multiple threads. Make your choice.

Share this post


Link to post
Share on other sites
Is it even possible to attempt to write a semaphore and come up with something worse than blizzard999 did? =p

A non-working, when it does work time slice eating semaphore!

Heh jk, anyway I hope no one is using a "semaphore" made like that.

Share this post


Link to post
Share on other sites
C/C++ cannot be used for safe multi-threading - you need external support written in e.g. asm, so that certain operatios can be defined as atomic. Obviously, most platforms provide this kind of functionality (Win32/Posix etc)

DO NOT try to roll your own locks/semaphores/mutexes etc. in standard C++ - it cannot be done properly.

Use something like boost::threads if you need multi-platofrm support.

Share this post


Link to post
Share on other sites
You can write code that will works perfectly fine in C/C++. Heck the algorithms even have names (Dekker's and Peterson's algorithms come to mind). A hardware solution will be much better but it's not like you can't do it in software.

Share this post


Link to post
Share on other sites
Quote:
Original post by O_o
Is it even possible to attempt to write a semaphore and come up with something worse than blizzard999 did? =p

A non-working, when it does work time slice eating semaphore!

Heh jk, anyway I hope no one is using a "semaphore" made like that.


What I wrote is the classic semaphore skeleton you should know.

If you have better and simple solutions to provide please explain it...otherwise you should be intelligent enough to shut up.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!