• Advertisement
Sign in to follow this  

Lock a bool?

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

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.

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
Thanks a billion. I don't use volatile much, I guess I need to do more reading.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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...

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement