Is my lockless data structure correct?

I need multiple read access to some data which can be updated from time to time.
I created a class for managing lock-less access to the data. The class uses 2 counters, one for count of the acquired references and another one for the count of released references. The update function replaces the data pointer and then waits for the completion of the previous reads.

Can someone with more experience in lock-less programming comment on the correction and performance of the code?

template
inline void IgnorePolicy(T* item) {}
template
inline void DeletePolicy(T* item) 
{   
    delete item;
}
template
inline void ReleasePolicy(T* item) 
{
    if(item != NULL)
        item->Release();
}

template
class ReadUpdateData 
{
    private:
        volatile int m_acquireCount, m_releaseCount;
        T* m_data;

        bool CheckReleaseCount(int limit) //wrap-safe check to see if release count has reached the required limit 
        {
            int releaseCount = m_releaseCount;
            return (limit = 0) ? limit = 0 && releaseCount < 0;
        }

    public:
        ReadUpdateData() : m_acquireCount(0), m_releaseCount(0), m_data(NULL) {}
        ~ReadUpdateData() 
        {
            assert(m_acquireCount == m_releaseCount);
            DestroyPolicy(m_data);
        }

        T* Acquire() 
        { 
            AtomicIncrement(&m_acquireCount); 
            return m_data;
        }
        void Release() 
        { 
            AtomicIncrement(&m_releaseCount); 
        }

        void Update(T* newData)
        {
            T* oldData = m_data;
            while(AtomicCompareExchangePtr(&m_data, newData, oldData) == oldData)
                oldData = m_data;   

            int acquireCount = m_acquireCount;
            while(!CheckReleaseCount(acquireCount))
                Yield();

            DestroyPolicy(oldData);         
        }
};

I'm not an expert, but I this line caught my eye:

volatile int m_acquireCount, m_releaseCount;

m_acquireCount and m_releaseCount will be part of the same cache line!

Therefor I expect no performance advantages compared to the simpler AtomicIncrement/AtomicDecrement on one variable.

StackExchange Code Review Q#9068, answer score: 3