How many threads is suitable?
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.
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
Tom
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.
However, the simplification offered in this respect is almost always outweighed by the complexity of sharing data across threads.
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
and in the thread
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.
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 itdata.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.
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.
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.
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.
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.
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.
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement