Hi, this is Jim Springfield. I’m an architect on the Visual C++ team.
In any concurrent application, protecting data from concurrent access is extremely important. There are many primitives that can be used for this, such as critical sections, mutexes, reader-writer locks, etc. There are also some newer high-level approaches to concurrency such as those provided by the Concurrency Runtime, although this isn’t the focus of what I’m showing here. However, there isn’t a good way in C++ to make sure that you are really protecting data correctly when accessing it from multiple threads. You will often see a comment (likely made by the original author) next to a member that reminds you to take some lock when accessing the data. There may be many data items all using the same lock and there may be more than one lock, with some data protected by one lock and some by another.
When it comes time to access some data from a member function, you have to start asking some questions. Who is going to call this member? What locks will already be held? Could I deadlock here? While I don’t have a solution to all of these, I do have a technique that allows you to be more aggressive with trying things and more comfortable with making changes to existing code, while guaranteeing that you don’t violate the requirement that a particular lock is held.
What I’m going to show is a way to associate a lock with a data member such that whenever that data member is accessed, a check is made that the proper lock is held by the thread. The basis for the technique uses native properties to provide access to data members. With a small set of macros, you can easily retrofit existing code to provide this benefit. I developed this technique years ago and I have used it in several code bases to catch problems with concurrent access.
Here is an example of something you will typically see in code. The developer has written that a critical section should be held when accessing m_rgContextsCache.
Wouldn’t it be great if this information could be specified in code AND enforced? The code below shows how to transform this into just that.
Now, whenever m_rgContextsCache is accessed, a user-defined function will be called if the proper lock is not held. What the macro does is to create the actual data member with a slightly modified name and a property with the name specified. Now, all you have to do is run your code and see if any errors occur. There is one “gotcha”. When members are initialized in the constructor or referenced in a destructor, the lock isn’t going to be held. For those cases, you need to directly access the member. A macro that translates a name into the modified “real” name can be used. It can also be used anywhere that it is specifically safe to access the member outside of the lock. The nice thing is that it is now very clear when you are doing this. Here is the code for this.
The PROTECTED_MEMBER macro is defined below. The first line creates the actual member. The second line creates the property and the remaining lines implement the get and put.
There are a couple of things that aren’t defined yet. The verify_lock function will return a boolean indicating whether the lock is held or not. These can be defined for any type of lock you use. There is also the _PROTECT macro. This should be defined to do whatever you want in the case of a failure. This could log, assert, crash, etc.
There are some other variations of the macro to handle some additional cases. One is to handle arrays. It provides a parameterized property which handles the index.
To handle a reader-writer lock, a slightly different macro is used. Instead of “verify_lock”, two other functions are used: verify_readlock and verify_writelock. Again, these can be user-defined to handle any type of reader-writer lock. There is one additional wrinkle here, however. There is a function defined called “GetWritable_##name”. The getter returns a const& to the underlying member and verifies that a read lock is held, but this won’t allow you to call methods on it that modify it. To do that, you have to explicitly call GetWritable_##name. This will return a non-const reference and verify the write lock is held.
There are a couple of other variations to the PROTECTED_MEMBER macro to handle some cases that can occur. If the data member can’t be assigned to (i.e. it is a type without assignment), we need to not provide a “Put” or we will get a compile error. Similarly, we may have a type that can’t be assigned from const data. These cases occur rarely in practice, but they do occur.
Finally, here are some examples of verify_lock and verify_unlock that can handle critical sections by pointer or by reference.
What I typically do is put all of these macros in a header file under an #ifdef _PROTECT guard. If _PROTECT is not defined, then I simply let everything collapse to simple data members. For release builds, the code is just as fast as before.
Finally, there is no good way that I’ve found to do this for global or static member data. Usually, it isn’t too much work to wrap global or static data into a class (along with the appropriate lock), which is what I’ve done when I need to.
This is actually pretty damn smart! I think you may have finally found a good use for VC++'s properties. I wish C++ had more contract support built in.
It's a shame this requires non-standard code.
When does standard C++ get properties? :p
I really like the idea. However, I have to ask: Doesn't this rely on undocumented implementation details of CRITICAL_SECTION?
As far as I have been able to determine, we are supposed to treat a CRITICAL_SECTION as an opaque handle. The fact that is actually a struct with a member called OwningThread is not something we are supposed to act on. The actual struct is subject to change in future versions of Windows, if I understand correctly.
Did I misunderstand something or did you really say you remove the concurrent access protections for release builds? Doesn't that defeat the purpose? Are all possible code/state paths exhausted in debug-build testing?
@Simon: The CRITICAL_SECTION struct is defined in the header. To be honest, I can't see it changing. Also, it is only being used here as a debugging aid.
@Joshua: Yes, this code adds some overhead and I only use it for debugging/checked builds. You could leave it enabled for release although I'm not sure what you could do other than exit the process. Whether all possible paths are exhausted during testing is up to your testing. I view these as ASSERTs, and I am asserting that the proper lock is held when accessing a member variable.
I see now. I thought the macros were implementing the locking as well as verifying it. I apologize for the misunderstanding. Nice post :-)