How should members of volatile class objects handle pointer and array members?

Question

I need to declare a class object as volatile:

int main() {
    volatile FixedQueue<Job, 5> q{};
    q.push({ 0x42, 0x55 });
}

I learned from this post that all member functions should be volatile so they can be called from a volatile object:

template <typename T, size_t N>
class FixedQueue {
public:
    FixedQueue() = default;

    constexpr void push(const T& obj) volatile {
        m_back = plusOne(m_back);
        *m_back = obj;
    }
private:
    T* plusOne(T* ptr) volatile { 
        if (ptr + 1 == m_data + N) return m_data;
        return ptr + 1;
    }

    T m_data[N]{};
    T* m_back{ m_data };
};

However, the compiler says invalid conversion from 'volatile Job*' to 'Job*', referring to return m_data, which leads me to believe that m_data is of type volatile T[]. To deal with this, I change plusOne()'s return type to volatile T*.

The error reappears but on the line m_back = plusOne(m_back);, which leads me to believe that m_back is of type volatile T*. I change plusOne's parameter type to volatile T*.

The error doesn't go away.

Where is this conversion happening, and what am I doing wrong?

---

Complete program (note that this is a simplified example of my actual program):

#include <stddef.h>
#include <stdint.h>

template <typename T, size_t N>
class FixedQueue {
public:
    FixedQueue() = default;

    constexpr void push(const T& obj) volatile {
        m_back = plusOne(m_back);
        *m_back = obj;
    }
private:
    volatile T* plusOne(volatile T* ptr) volatile { 
        if (ptr + 1 == m_data + N) return m_data;
        return ptr + 1;
    }

    T m_data[N]{};
    T* m_back{ m_data };
};

struct Job{ uint8_t byte; uint8_t addr; };

int main() {
    volatile FixedQueue<Job, 5> q{};
    q.push({ 0x42, 0x55 });
}

Answer 1

volatile is the wrong thing, or rather insuficient.

volatile indeed means that every read and write is observable and must not be optimized away. But it also means it can't be optimized away.

What it does not mean is that it can't be interrupted. So in your code

m_back = plusOne(m_back);
*m_back = obj;

there is no guarantee an interrupt won't fire between the first and second line or in the middle of plusOne. If obj is larger than the CPU can write in one go there might even be an interrupt in the middle of writing obj.

You can only use volatile with objects that are naturally atomic on the CPU and for operations that are atomic. Beyond that you need more.

For multithreading this is solved with atomic<T>, ensuring different threads don't interfere with each other. But that doesn't work for interrupts.

To make your queue interrupt safe you have to add calls to disable/enable interrupts to make larger operations become atomic. The smartest way to do that would be like the lock_guard with RAII. If your runtime doesn't already have something for it create a class CriticalSection that disables interrupts in the constructor and reenables them in the destructor. Bonus points if you make it reentrant using a static int count = 0;.

You can mark your member variables volatile to guarantee values are always read from ram and written back to ram but as said that prevents any optimization. A better way is to include a memory barrier in the CriticalSection constructor and destructor. This will allow the compiler to optimize while within the critical section where interrupts are disabled but not across those barriers. So everything is read from ram when entering the critical section and written back before leaving but while within things can use registers.

You can use atomic load/store for the count and use the existing barriers for that purpose.

---

Update: This is how the CriticalSection could look like:

class CriticalSection {
    public:
    CriticalSection() {
        asm("cli":::"memory");
        ++count;
    }
    ~CriticalSection() {
        if (--count == 0) {
            asm("sei":::"memory");
        } else {
            asm("":::"memory");
        }
    }
    private:
    static inline int count = 0;
};

The cli and sei make operations atomic and the memory clobber produces a compiler barrier that prevents optimizations of reads and writes across it. This eliminates the need for any volatile.

Usage is like this:

constexpr void push(const T& obj) {
    CiritcalSection t;
    m_back = plusOne(m_back);
    *m_back = obj;
}