Lock a bool?

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.

Thanks a billion. I don't use volatile much, I guess I need to do more reading.

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.

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.

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.

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).

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.

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...