Sign in to follow this  

Multi threading question.

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

This topic is 3378 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this