If the locks make sure only one thread accesses the locked data at a time, then what controls access to the locking functions?
I thought that boost::mutex::scoped_lock should be at the beginning of each of my functions so the local variables don’t get modified unexpectedly by another thread, is that correct? What if two threads are trying to acquire the lock at very close times? Won’t the lock’s local variables used internally be corrupted by the other thread?
My question is not boost-specific but I’ll probably be using that unless you recommend another.
You’re right, when implementing locks you need some way of guaranteeing that two processes don’t get the lock at the same time. To do this, you need to use an atomic instruction – one that’s guaranteed to complete without interruption. One such instruction is test-and-set, an operation that will get the state of a boolean variable, set it to true, and return the previously retrieved state.
What this does is this allows you to write code that continually tests to see if it can get the lock. Assume x is a shared variable between threads:
Since the other threads continually test the lock until they’re let into the critical section, this is a very inefficient way of guaranteeing mutual exclusion. However, using this simple concept, you can build more complicated control structures like semaphores that are much more efficient (because the processes aren’t looping, they’re sleeping)