Sign in to follow this  

Threading and the Intel Thread Checker

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

The Intel Thread Checker doesn't seem to like my threading practices. It displays these nice red errors every time it detects a write-read race. For example: One thread is executing this code:
time_elapsed = Timer.GetTimeElapsed();
g_time += time_elapsed;  //time incremented each millisecond
Sleep(1);
Another thread is executing:
float mytime = g_time;
//grab time each frame; every ~17ms
The first thread is changing the global time value (g_time) with an atomic operation. The 2nd thread is reading g_time with an atomic operation. I see the problem in that the 4 bytes of memory is being written to and read from at the same time, but isn't this memory access problem solved with the motherboard? Doesn't the mobo control this access in hardware, and shouldn't it have less overhead and latency than any software solution like a mutex? Now the real problem is that the write-read race is not just in the threaded timer. There are 500+ objects in our game that are being updated on separate cores. Is it practical to wrap every object in a mutex? I'm not terribly worried about creating 500+ mutexes, but I am worried about the overhead of locking the mutex everytime any object wants access to the other object's variables. So in short: Is a write-read race that bad? Is it unsafe? Is it possible to see a speed increase by eliminating the race with a mutex? Thanks for any help.

Share this post


Link to post
Share on other sites
You are claiming these are atomic operations when in fact they are not.

g_time+= time_elapsed;

Memory is probably copied to registers, then registers are added, then flushed back to memory. The thread could be preempted at any point during those instructions.

Look up InterlockedIncrement and InterlockedExchange, which could help you with the case you described.

In terms of accessing variables from objects you have there are several options, the one you described might be overkill, another option would be to double buffer your game objects and synch them on each frame.

Share this post


Link to post
Share on other sites
Another option would be to use volatile for g_time, I belive on VS 2005 volatile adds memory barries which would also solve your problem.

Share this post


Link to post
Share on other sites
I see. Thank you for the information. InterlockedIncrement and InterlockedExchange seem to work for integers. Is there a floating point version, or should I just use InterlockedExchange to copy the 4-bytes of memory atomically.

Thanks for the help.

Share this post


Link to post
Share on other sites

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