Jump to content
  • Advertisement
Sign in to follow this  
jsg007

Multi threading question.

This topic is 3588 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

Hi there, I am planning to separate my physics from graphics in another thread. But I am not sure how should I make the two of them communicate. I was thinking of doing a simple messaging system, in which the two threads communicate. However I am not sure if it is a right thing for two threads to read/write the same memory zone (let's say a std::vector of messages). How would you suggest to do this properly?

Share this post


Link to post
Share on other sites
Advertisement
There is a lot to know about multithreading... you might want to look at Boost::Thread to see which primitives are available for such tasks.
I've never had much to do with this, but AFAIK reading is OK most of the time. Writing must be done carefully: you should avoid that a non atomic operation breaks due to another thread changing the sanme data at the same time:

suppose that there is a thread that takes your password and reverses it.
suppose that there is another thread that takes your password and encrypts it.

If these operations are not atomic and the two threads are not syncronized, you may end up with a mess.

So you must stop your encryption until the reverser ends its job.

There are a few primitive (locking, semaphores and so on) that help you do that.

Share this post


Link to post
Share on other sites
Standard library makes no thread safety guarantees. As such, the communication channel must be manually accessed in thread-safe manner.

If std::vector is used, then each time you access it, you must use a mutex to lock entire vector to prevent concurrent modification.

Most accessible way is boost::thread or POSIX threading library (pthreads). Windows-specific critical sections do the same (they are used by above libraries internally.


It should be noted however that thread synchronization is tricky in that improper locking can result in situation where mutli-threading brings no advantage. The proper way to design such a system is not trivial, perhaps the only general guideline is to minimize number of locks.


When passing messages between threads, this can be done through batches. Rather than locking on each access to vector, have produces maintain its own local copy. Every once in a while, it submits entire vector once (using a lock). Rather that popping single message at a time, consumer then receives a batch of messages to process.


It should also be noted that physics simulations are typically double-buffered. You have two full states, one old (T-1) and one new (T). If you design an application in such a way that old state is always read-only, then there is no need for synchronization, and rendering thread (for example) can access it at will. As long as you can enforce the old/new constraint, this method results in almost completely independent systems, resulting in high degree of concurrency.

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!