如何编写安全的原子对象包装器？

Question

I've been attempting to write a wrapper class to wrap Win32 intrinsic function such as InterlockedIncrement , InterlockedExchange . Although my problem is probably analogous on other platforms which support similar intrinsics.

I have a basic template type:

template <typename T, size_t W = sizeof(T)>
class Interlocked {};

Which is partially specialized for datatypes of different size. For example, here's the 32 bit one:

//
// Partial specialization for 32 bit types
//
template<typename T>
class Interlocked <T, sizeof(__int32)>
{
public:

    Interlocked<T, sizeof(__int32)>() {};

    Interlocked<T, sizeof(__int32)>(T val) : m_val(val) {}

    Interlocked<T, sizeof(__int32)>& Interlocked<T, sizeof(__int32)>::operator= (T val)
    {
        InterlockedExchange((LONG volatile *)&m_val, (LONG)val);
        return *this;
    }

    Interlocked<T, sizeof(__int32)> Interlocked<T, sizeof(__int32)>::operator++()
    {
        return static_cast<T>(InterlockedIncrement((LONG volatile *)&m_val));
    }

    Interlocked<T, sizeof(__int32)> Interlocked<T, sizeof(__int32)>::operator--()
    {
        return static_cast<T>(InterlockedDecrement((LONG volatile *)&m_val));
    }

    Interlocked<T, sizeof(__int32)>& Interlocked<T, sizeof(__int32)>::operator+(T val)
    {
        InterlockedExchangeAdd((LONG volatile *)&m_val, (LONG) val);
        return *this;
    }

    Interlocked<T, sizeof(__int32)>& Interlocked<T, sizeof(__int32)>::operator-(T val)
    {
        InterlockedExchangeSubtract((LONG volatile *)&m_val, (LONG) val);
        return *this;
    }

    operator T()
    {
        return m_val;
    }

private:

    T m_val;
};

However, I'm coming to the conclusion that I don't know how to safely write such an object. Specifically, I've realised that returning *this after performing an interlocked operation allows the possibility for another thread to alter the variable before it's returned. This nullifies the point of the type. Is it possible to write such a thing? Presumably std::atomic solves this problem but I don't have access to that in my compiler...

Answer 1

如果您没有std::atomic ，则可以使用boost::atomic （出现在最新的Boost 1.53中 ），它已经过跨平台实现的良好测试。

Answer 2

Operators + and - are meaningless. What you've actually implemented looks more like compound assignment ( += , -= ) but you need to return a value of type T and not a reference to (*this) . Of course this isn't following the conventions for assignment operators... std::atomic chooses to use named functions and not operator overloads for everything except ++ and -- , probably for that reason.

Answer 3

You have a data race in your code

You can simultaneously write to a variable (using InterlockedBlah(...)) and read from it using operator T.

The memory model for C++11 states that this isn't allowed. You could possibly rely on the hardware specification for your platform which may state that 4 byte (aligned!) reads don't tear but this is brittle at best. And undefined behavoir is undefined.

Also, the read doesn't have any memory barriers [which tell both the compiler and the hardware] not to reorder instructions.

Making the read an return InterlockedAdd(&val, 0) operation would probably solve all these, as the Interlocked APIs on windows are guaranteed to add the right memory barriers. However, beware of Interlocked* APIs on other MS platforms which don't have this guarantee.

Basically what you're trying to do is probably possible but really hard, and definitely relies on what the software and hardware guarantees on each platform - it isn't possible to write this in a portable way.

Use std::atomic, use boost::atomic

Answer 4

Aside from the very good advice of "use someone else's already tested and working implementation" from nogard, I would suggest that you don't want to return *this , but the result of the operation - this is how the existing interlocked operators work (and how std::atomic works).

So in other words, your operator code should look like this:

T Interlocked<T, sizeof(__int32)>::operator+(T val)
{
    return InterlockedExchangeAdd((LONG volatile *)&m_val, (LONG) val);
}

There is a problem, as Ben Voigt poinst out that that this function modifies the input value, which means that:

a = b + c;

would actually do:

b += c; 
a = b;

Answer 5

Consider two threads performing concurrent additions on your atomic number class, where Thread #n adds an amount t_n to your number x .

You are worried that between performing the addition and returning the result in one thread, a second thread might perform an addition, thus messing up the return value for the first thread.

The observed behavior for a user of the class is then that the return value is (x + t_1 + t_2) instead of the expected (x + t_1) .

Now let us assume you had an implementation that would not allow that behavior, ie the result is guaranteed to be (x_1 + t_1) , where x_1 is the value of the number immediately before Thread #1 performs its addition.

If Thread #2 performs its concurrent addition immediately before Thread #1 the value you get is:

(x_1 + t_1) = ((x + t_2) + t_1)

Which is the exact same race . Unless you introduce some additional synchronization or a check for the expected value of the number before applying the addition, you will always get this race.