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.