jaredpar's WebLog : Templates

Thread Local Storage template

Jared Parsons — Mon, 21 Apr 2008 20:52:03 GMT

Thread local storage is another method of synchronization between threads. It is different that most synchronization cases because instead of sharing state between threads it enables developers to have independent, thread specific pieces of data which have a similar or common purpose.

The uses of thread local storage (TLS) vary greatly but is a very powerful and lightweight method for storing data. TLS can easily be envisioned as a giant void* array for every thread. The entry point, TlsAlloc, provides an index into this array and allows the storage of arbitrary data [1].

TLS is particularly useful for storing state information. For example, one of my components lives in a highly multi-threaded environment. Each thread serves essentially the same purpose and has the same states and state transition semantics. Like any good paranoid programmer I wanted to add contracts to check my state transitions and semantics.

Contract.VerifyState(ExpectedState, ???CurrentState)

The question is where to store the state information for a thread? A global state variable won't suffice because there are N threads. A global array of state information also has it's share of problems: synchronization, determining an index, lifetime.

TLS is ideally suited to this scenario. Each thread has an independent but similar concept of state. In my initialization code I allocate an TLS index and now I have a place to store my state.

Contract.VerifyState(ExpectedState, *TlsGetValue(g_stateTlsIndex)

The next question is how to manage the lifetime? TLS provides a void* and the caller must manage the lifetime of the allocated memory. Since this is thread specific the ideal place is to manage the memory in the thread startup proc. However I don't own the creation of the thread, my component is called on a number of threads so this won't work.

The solution is to use the stack. The initial return for TlsGetValue is NULL. If this situation is detected then the current stack frame is set to own the memory for the slot. Further accesses to the value do not own the memory and simply access it. The semantics are straight forward but annoying to constantly rewrite, so naturally write a template :)

    template <typename T>
    class TlsValue
    {
    public:
        TlsValue(DWORD index, const T& defaultValue=T()) :
            m_pValue(NULL),
            m_index(index),
            m_owns(false)
        {
            m_pValue = reinterpret_cast<T*>(::TlsGetValue(m_index));
            if ( !m_pValue )
            {
                m_pValue = new T(defaultValue);
                m_owns = true;
                ::TlsSetValue(m_index, m_pValue);
            }
        }
        ~TlsValue()
        {
            if ( m_owns )
            {
                ::TlsSetValue(m_index, NULL);
                delete m_pValue;
            }
        }

        T* Value() const
        {
            return m_pValue;
        }

    private:
        // Do not auto generate
        TlsValue();
        TlsValue(const TlsValue<T>&);
        TlsValue& operator=(const TlsValue<T>&);

        T* m_pValue;
        DWORD m_index;
        bool m_owns;
    };

In addition to this blog post, I added a working sample to http://code.msdn.microsoft.com/TlsValue. This is my first attempt at posting a sample on http://code.msdn.com so please provide any and all feedback on the data.

[1] This is similar to data marked with the ThreadStatic attribute in managed code without all of the slot messiness and with the added benefit of strong typing.

Gotcha: CComPtrBase assignment

Jared Parsons — Tue, 08 Apr 2008 18:44:16 GMT

Today what started out as a crash due to a pure virtual call turned into finding a gotcha in CComPtrBase<T>. Essentially the code in question boiled down to the following. Can you spot the problem?

void GetAStudent(CComPtrBase<T> &spStudent)
{
    CComPtr<Student> spLocal;
    // Do some operation to get a student
    spLocal = spStudent;
}

The problem isn't apparent until you look at the definition for CComPtrBase<T>::operater =. See the problem? Basically CComPtrBase<T>::operator= isn't explicitly defined. This means that C++ will automatically implement memberwise assignment. The RHS of the operator= will be a "const CComPtrBase<T>&".

CComPtr<T> derives from CComPtrBase<T> therefore it satisfies this and a memberwise assignment will occur. We now have two smart pointers on the same value. However the second smart pointer, CComPtrBase<T>, did not perform an AddRef. So when both objects are destroyed there will be an extra Release and hopefully a crash.

The fix?

Use CComPtr<T> or CComPtrEx<T> instead of CComPtrBase<T>
Less Optimal: call AddRef() on spLocal.

Reference values in C++

Jared Parsons — Thu, 03 Apr 2008 17:24:54 GMT

Reference values are a powerful feature of C++ but I find they have one significant detractor. A developer can not look at an API call and determine if a parameter is being passed by reference or value (VB has the same problem).

IMHO this is one item that C# got 100% correct. In C# developers must say a value is out/ref or a compile error results. Forcing both the API declaration and usage to specify the reference semantics makes code much more understandable. When you look at an API call there is absolutely no question about the byref/byval/out semantics of a parameter.

Internally I've met people who are hesitant to use reference parameters in C++ because of the ambiguity. Not making it declarative in both places meant unexpected behavior could occur in a number of scenarios. I agree with this statement.

But hey we're talking about C++ here. Any C++ problem can be fixed with some macros and a template right? I thought about this over the weekend and came up with a quick sample. Note, I haven't extensively tested this sample yet so there may be bugs. However it gets the base cases right.

The goal of this API is to allow API authors to force developers to be explicit about their ByRef semantics. It will prevent developers from silently passing a value by ref and hence getting unexpected behavior. Failure to do so will result in a compile time error. Also there is a minor bit of indirection overhead for debug mode but in retail this will compile out to normal code.

#ifdef DEBUG

template <typename T>
class ByRefType
{
public:
    explicit ByRefType(T& arg) : m_ref(arg)
    {
    }

    operator T&() const 
    {
        return m_ref;
    }

    ByRefType& operator=(const T& value)
    {
        m_ref = value;
        return *this;
    }

private:
    ByRefType();

    mutable T& m_ref;
};

template <typename T>
ByRefType<T> MakeByRefType(T& expr)
{
    return ByRefType<T>(expr);
}

#define ByRef(expr) MakeByRefType(expr)
#define ByRefParam(type) ByRefType<type> 

#else

#define ByRef(expr) expr
#define ByRefParam(type) type&

#endif

All well and good. Now we can attribute byref paramaters with ByRefParam() and force callers to tag it as a ByRef argument.

void SimpleByRef(ByRefParam(int) i, int newValue)
{
    i = newValue;
}

void Test()
{
    int i1;
    SimpleByRef(ByRef(i1), 5);
    SimpleByRef(i1, 6);     // Compiler Error!!!
}

As said before, this is an initial implementation and I expect updates as I use this in code and find bugs. Please post back with any you find.

Multiple paths to IUnknown

Jared Parsons — Fri, 22 Feb 2008 09:21:00 GMT

ATL has a lot of great tools for COM programming and CComPtr is a good example. It's a smart pointer class which manages the reference count of an underlying COM object.

One of it's limitations though is it will only work properly when the inheritance chain for a class has only one path to IUnknown. If it has more than one path, the following error will be issued when you attempt to assign a value of type T to the CComPtr.

error C2594: 'argument' : ambiguous conversions from 'SomeClass *' to 'IUnknown *'

The reason behind this is the operator= for CComPtr uses AtlComPtrAssign to change the references. The right hand side of the assignment is passed to this function as IUnknown. Since there are multiple paths to IUnknown the C++ compiler cannot implicitly perform the cast and issues the above error.

I most frequently encounter this error in larger code bases with older classes. New functionality is needed so I add a new interface and end up with a lot of C2594 errors.

To work around this I defined a new CComPtr class named CComPtrEx which inherits from CComPtr base. It defines the same operators as CComPtr but uses a Copy Constructor and Swap to perform the = which gets around the multiple paths to IUnknown. The rest of the functions are identical to CComPtr.

template <class T>
class CComPtrEx : public CComPtrBase<T>
{
public:
    CComPtrEx() throw()
    {
    }
    CComPtrEx(int nNull) throw() :
        CComPtrBase<T>(nNull)
    {
    }
    CComPtrEx(T* lp) throw() :
        CComPtrBase<T>(lp)
    {
    }
    CComPtrEx(_In_ const CComPtrEx<T>& lp) throw() :
        CComPtrBase<T>(lp.p)
    {
    }

    T* operator=(_In_opt_ T* lp) throw()
    {
        if(*this!=lp)
        {
            CComPtrEx<T> sp(lp);
            Swap(&p, &sp.p);
        }
        return *this;
    }

    T* operator=(_In_ const CComPtrEx<T>& lp) throw()
    {
        if(*this!=lp)
        {
            CComPtrEx<T> sp(lp);
            Swap(&p, &sp.p);
        }
        return *this;
    }
};

C++ Placement New: Tracking down a crash

Jared Parsons — Thu, 18 Oct 2007 20:05:06 GMT

See my previous two posts on an introduction to placement new if you are unfamiliar with the subject.

Recently I did a bit of work on the heap management story for our code base. Mainly it was a change to unify the different ways we accessed our internal heap. In the process I unified our operator new story. Part if this involved unifying our placement new allocation overloads. We have several allocators in our code base and I noticed we had several overloads which essentially did the same operation

static inline
void * _cdecl operator new(size_t cbSize, MyCustomAllocator &allocator)
{
    return allocator.Alloc(cbSize);
}

static inline
void * _cdecl operator new(size_t cbSize, MyCustomAllocator *allocator)
{
    return allocator->Alloc(cbSize);
}

This seemed a bit redundant to me so I deleted the one which contained a pointer overload. A while later I tested my changes and our application almost immediately crashed. It only took a few minutes to discover the problem. We had a lot of operations that followed this pattern.

Student *p = new (pAllocator) Student();  // pAllocator typed to MyCustomAllocator*

As I said in my previous posts, new is just another C++ function. As such it participates in overload resolution. This code now binds to the placement new operator and not the placement allocation overload which takes a reference. At first I thought about using a regex search and replace to solve the issue. However I decided this wasn't a complete solution. There is no guarantee that my regex will catch every case and any case I miss won't crash until we actually hit the line of code.

The best case scenario here is to turn that line into a compile error. That would guarantee that I fix every location that is a problem. Since new participates in overload resolution you can solve this with a template.

template <typename T>
static inline
void* _cdecl operator new(size_t cbSize, T* allocator)
{
    allocator->ThisWillForceACompileError();
}

This caused all places where a pointer type was passed to new which wasn't explicitly "void*" to turn into a compiler error. This quickly outlined all of the places I needed to fix up and guaranteed that my fix didn't allow developers who were accustomed to using a pointer to the allocator to accidentally introduce a bug into the code base (myself included :)).