[cfe-dev] Proposal for thread safety attributes for Clang

Bjorn Reese breese at mail1.stofanet.dk
Sat Jul 2 02:24:07 PDT 2011


Caitlin.

The two problems you address can be handled with templates instead of
annotations. While the techniques mentioned below do not solve all
thread-safety problems, they do solve the most common ones that I have
encountered. And none of them requires extensions to the compiler.

ACQUIRED_AFTER: Some deadlocks occur because you need to lock two
mutexes, A and B, and you accidentially lock A before B in one function
and B before A in another function. Such deadlocks can be avoided with
the Boost.Thread locking functions [1], as it guarantees that a list of
mutexes always is locked in the same order, regardless of the order you
list them.

GUARDED_BY: It is true that the C++ compiler does not know which mutex
guards what variables, and therefore cannot alert you if you, say, use
a variable without locking its mutex. I solved this problem in a
commercial project by defining two templates: a guard and an accessor.
The guard contained the mutex and the variable (or struct of
variables) as a private member, and only the accessor could access it.
The accessor would lock and unlock the mutex in a RAII manner. An
example using this technique could look like this:

   class Alpha
   {
   public:
     int GetValue() const
     {
       const_unique_access<int> value(valueGuard);
       return *value;
     }
     void SetValue(int v)
     {
       unique_access<int> value(valueGuard);
       *value = v;
     }
   private:
     unique_access_guard<int> valueGuard;
   };

This solution shares some traits with Anthony Williams' Synchronized
Values [2].

[1] 
http://www.boost.org/doc/libs/1_46_1/doc/html/thread/synchronization.html#thread.synchronization.lock_functions
[2] http://drdobbs.com/cpp/225200269



More information about the cfe-dev mailing list