Lock a bool?
Author
If the data shared between multiple threads is a bool do you need to lock it between reads and writes when only one thread does the witting?
I plan on separating my windows update pump from the rendering thread and I need to know when to quit (only happens once) and when the screen resolution has changed (will be a very rare event) and locking a mutex once/frame seems like a bad idea. Locking once every 10 frames doesn't sound much better either. But if all I need to sync is a bool and all I check is wether or not it is true (non zero), then I don't see how not locking could cause a problem.
I imagine that the worst that could happen is the bool gets changed and that update is missed for 1 frame.
Mark it as volatile.
I was brainstorming on the concept of concurrent bool value access before, and whether it's possible for it to be corrupted in the first place (assuming only valid values get written to it in the first place), but didn't really find anything too dramatic about it.
Also, locking once per frame means 500 locks per second max, usually 50-150. If you use any semi-decent lock implementation, it'll be fast enough.
For the reference, the networking system I was testing handled some 20,000 messages per second, with 3 (or 2, depends on receive/send) different locks per message, and 20 threads total. By the time network capacity was maxed out, CPU on single core was at around 15%.
So even if you choose to lock it, it's not that bad.
I was brainstorming on the concept of concurrent bool value access before, and whether it's possible for it to be corrupted in the first place (assuming only valid values get written to it in the first place), but didn't really find anything too dramatic about it.
Also, locking once per frame means 500 locks per second max, usually 50-150. If you use any semi-decent lock implementation, it'll be fast enough.
For the reference, the networking system I was testing handled some 20,000 messages per second, with 3 (or 2, depends on receive/send) different locks per message, and 20 threads total. By the time network capacity was maxed out, CPU on single core was at around 15%.
So even if you choose to lock it, it's not that bad.
A mutex would have been massive overkill for that kind of thing anyway.
A simple critical section would have been more than sufficient.
Using InterlockedIncrement would do the trick nicely.
However, simply marking the variable as volatile should be enough in this case.
A simple critical section would have been more than sufficient.
Using InterlockedIncrement would do the trick nicely.
However, simply marking the variable as volatile should be enough in this case.
InterlockedIncrement / Decrement is designed for this type of synchronization. If the memory for the variable is aligned correctly, the operations are guaranteed to be atomic; that is, the value doesn't change in the middle of the call. Also, said functions are relatively light-weight.
Using volatile variables will make some compiler optimizations impossible or difficult, so I recommend avoiding the keyword if possible.
Using volatile variables will make some compiler optimizations impossible or difficult, so I recommend avoiding the keyword if possible.
A single write is guaranteed atomic, the issue comes if you do a test/write pair in the writing thread. In the former case a simple assignment will be fine. Otherwise you'll need InterlockedIncrement or such.
Either way, you should mark the variable volatile.
Either way, you should mark the variable volatile.
Also, if you read the bool multiple times in the same thread for a single frame, make a copy of it at the start of the frame to ensure its value is consistent throughout that frame (assuming that's the behaviour you want, of course).
Author
Thanks for all the help. I still need to learn about InterlockedIncrement but it looks like a windows only thing. I wanted to use boost::threads for all my multi-threading needs. Although I do realize that the threads library is not complete.
Quote:Original post by T1Oracle
Thanks for all the help. I still need to learn about InterlockedIncrement but it looks like a windows only thing. I wanted to use boost::threads for all my multi-threading needs.
boost::threads uses appropriate platform counter-parts in threading library, which is one reason why it makes sense to use it.
I won't guarantee about details of which gets used where, but last time I checked, the implementation looked quite efficient.
Author
Well that's reassuring. I remember seeing some warning in the boost documentation not too long ago, but now I can't find it. Whatever...
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
