部分更新复杂的C11原子类型和非原子读取优化

Question

I think the easy way to describe my question is to demonstrate it in code, so here is a contrived example in C to highlight the issues I am interested in answering:

// Just some complex user defined type
typedef struct {
    ...
} state_t;

typedef struct {
    state_t states[16];
} state_list_t;

static _Atomic state_list_t s_stateList;
// For non-atomic reads
static state_t * const s_pCurrent = &s_stateList.states[0];

// Called from external threads
void get_state(state_list_t * pStateList)
{
    *pStateList = atomic_load(&s_stateList);
}

// Only called by 'this' thread
static void update_state(struct state_data_t const * pData)
{
    state_list_t stateList = atomic_load(&s_stateList);
    for (int i = 0; i < 16; i++)
    {
        // Do some updating on the data
        do_transition(&stateList[i], pData);
    }
    atomic_store(&s_stateList, stateList);
}

// Only called by 'this' thread
static void apply_state(state_t const * pState)
{
    atomic_store(&s_stateList[0], *pState);
}

// Only called by this thread
static bool check_state()
{
    // Check (read) some values in the current state
    return isOkay(s_pCurrent);
}

First, my apologies for any syntax errors, but this should get the point across...

The first two functions are pretty straight forward usage of the C11 atomics, namely one thread is reading a value that another one is writing. My specific questions are really regarding the last two functions, apply_state, and check_state, and it really just boils down to whether these are okay things to do.

In apply_state, you can see that it is only updating part of the structure atomically, specifically, the first element of an array. It is my understanding that essentially every element of the _Atomic s_stateList is considered atomic (much like volatile), so the compiler is fine with the atomic_store call, but can this happen while another thread is 'atomically' reading from the object (ie in get_state), or is the synchronization essentially equivalent to a locking / unlock the same mutex in each call? I could see how it is possible that since it is basically a different variable (well, okay same address, but what if I used states[1]?) it could result in a different mutex being used. Also, what happens if state_t happens to be lock free?

I'm more confident that the check_state function is an okay thing to do here, because it only performs a read on an object that is modified only by the same thread, but I'm wondering if I'm missing anything here. I've just recently discovered that accessing an atomic variable directly (I think via assignment or function argument) is treated exactly like a call to atomic_load() or atomic_store(), so I am wondering if keeping a private reference for non-atomic reads is a worthwhile optimization, or if the compiler is otherwise smart enough to accomplish similar optimization on its own.

Edit: The result is undefined when dereferencing a non-atomic pointer to an atomic value.

Answer 1

No this doesn't fit into C11's model for atomics, and for good reasons. _Atomic is only syntactically a qualifier, semantically an _Atomic is a new type. This is reflected by the fact that the standard allows that size and alignement of such types are different from those for the base.

In your case of a wide atomic type, a permitted implementation of the atomic type is to add a hidden field to the struct that serves as a lock. Generally, such types are implemented as "not lock-free" that is with some hidden state (within the struct or seperately) that controls access to the data.

The standard can only guarantee you racefreeness by stitching together an access model. If you ask your whole data to be accessible atomic (in the sense of indivisible operations on that whole data at once), the model only allows you exactly that.

Accessing individual fields of an atomic object has undefined behavior. That means if your platform had specific properties it could allow you access to individual fields. You'd have to read up your platform's documentation and hope for the best, in particular that they don't change things from one version (compiler, processor, ...) to another.